Agile is not synonymous with Un-preparedness

Many a times, in name of agile, I have heard that

1. Planning isn't necessary, as we need to work on what comes our way.
2. Control of work is to be eliminated as members will pick the next story once they finish their current load,
3. Clients are free to submit the changes they want and move it to iterations or extend the schedules of Sprints,
4. Technology and architecture (code in software/IT) can be modified at later time and redone as the requirements evolve anytime during the course of the project.
5. Team members can come and go and will only be retained for the part they need to spend their timeand many similar stories...
6. These are perceptions that are difficult to change and are needless to be associated, just because the word "agile" loosely means "flexibility".

In fact to be agile, it requires a great amount of preparedness. Each stakeholder (Client, Sponsor, Reviewers, Consultants, Vendors, Developers, Designers, Testers, Support staff) all require to posses in themselves:

1. Attitude, Alertness, Adaptiveness, Swiftness, Resourcefulness, Decisiveness on the job
2. Abilities to present, praise, practice, preach and be with passion through to the job sign-off
3. Accept self-introspection, Admit faults in open, Assess the future state continuously
4. Channelize the learning, Champion a cause, Customize their skills

It will be great to see results from agile implemented as a people practice and the team transforming their project and results experience rather than the other way around.

Social Management through SCRUM

SCRUM teaches you to go social with your project management skills. And this is where traditional managers get uncomfortable at the thought of letting the control go. 

It heralds you to use tools that are accessible and editable by project teams than relying on specialized management software. It exposes project managers who create their specialization in usage of tools to focus on people advocacy than glancing through charts and making paper models of project completion.

SCRUM is right approach for those who believe that it is the feeling of togetherness in the process of deliveries that is important for a self actualized (in Maslow terms) working than just getting there.

Sprints as a Number or a Named Instance ?

Do you call your sprints as sprint 1, 2, ... or do you assign names to your sprint ?

This post shares my experiences and thoughts based on the various views that I have encountered with my teams.

1. Numbered Sprints are a great motivator. When you start saying Sprint 5, 9, 15, it really gives you the pleasure to know that earlier sprints had a successful closure. This itself motivates the team to conclude sprints with an actionable product and refer to the finished product at each sprint as proof of their capabilities.

Named Sprints are referencible and give a direction during the current sprint. The practice of code names for products under production comes from product manufacturing industry. The code names for Sprints orients the team and when talking instead of an arbitrary number. The name tends to bring about cohesiveness in teams, particularly when you are establishing sprint teams.

2. Numbered sprints become quite flexible as there are no boundaries established in the minds of stakeholders. Hence there are chances to add/modify priorities and user stories in sprints although SCRUM disallows this practice. It is difficult when stakeholders are new to SCRUM and wish to have many features in a single Sprint.

Named Sprints has potential to live up to the name and can ward off intrusions. Once the name of Sprint is decided with stakeholders, it kind of acts as a barrier for inserting more features that do not live upto the principle and Sprint Vision in the overall product vision.

3. Numbered Sprints are difficult to run in parellel. Again since numbers hold a sequence, stating that Sprints 3,4,5 are running with parellel teams, becomes cumbersome to manage and remembering the priorities of each.

Named sprints are good to align parellel sprints. I normally have a sprint called "libs and interfaces" that run in parellel to initial few sprints. It then makes it easy for me to have other sprint leads ask/discuss the features that can be a global library rather than reinventing the wheel within individual sprint teams. Thus  for effective architecture and design, named sprints become ideal for user story transfers.

4. Numbered sprints do not lend themselves to reporting well. For example, when comparing velocities and individual sprint team performances with stakeholders regarding complexities and user story completions vs iterations in sprints, it is difficult to visualize the working of the team.

In Named sprints, it is automatic to gauge the performance against the metric numbers as the names of the sprint and the numbers seemingly make a sense. I realized this because I use EVM for reporting. I initially used to report performance week wise, then tried to report it as Sprint numbers, but when speaking of numbers with respect to a phase/name of sprint, it is good to debate and understand the variances.

This is a matter of cultural taste and the SCRUM implementation maturity within your organization. To date, either of the projects (numbered sprints or named sprints) have been successful for me in aligning business goals to project results. So far, I do not have emperical evidence to prove if a numbering or naming sprints is good. May be few more experiments might yield some direction and shape up my personal preferences.

Has this topic been a concern in your work sphere? Is there a standard SCRUM terminology that needs to be adhered ? Are there any related experiences that you can share ? Looking forward for best practice evolution with collective intelligence.

SCRUM Survival - Key Mistakes in Initial Change of Guard

If you are an initiator:
1. Do not make the mistake of saying "We do not need project managers" and "SCRUM Masters are there to replace them".

2. Do not bring in a critical project to showcase benefits of SCRUM. Odds for gaining buy-in are always remote. It will be relegated to a one time wonder or considered an extreme measure. In critical projects, only people and results are spoken well, not the process or the way it was done. So never pick a critical or riskier project for SCRUM adoption. You are never going to get it past this one project.

3. SCRUM is meant for projects where details can evolve, but not the requirements, design or end solution. Do not make the mistake of saying "Since we are following Agile, you can keep giving new requirements in every Sprint". In SCRUM there is a need for Project/Product vision, define technologies, architecture, have a blueprint ready and all requirements planned for sprints in advance. It is only the details that can evolve, not the requirements. NOTE that evolving requirements projects will fail neverthless if it is SCRUM or not.

4. Sprints are not discrete events. They need to be continous. One of the anti patterns of SCRUM initiation is to conduct a sprint or couple of sprints, then evaluate that it is not working. Or pace out time gap between 2 Sprints. As with 10,000 hour rule, you need minimum of 10 Sprints or roughly 30 weeks to evaluate goodness of SCRUM and it needs to be analogous.

5. Reducing Retrospective to a paper process and not learning from it: I renamed them as "Refreshpectives" in my implementation. Somehow, to me, retrospective conveys meaning of just analysis and historical value. Refreshpective to me gives more meaning that you refresh what happenned and DONT REPEAT what was not correct. SCRUMs or subsequent Sprints suffer from mental blocks and tunnel visioning if Refreshpectives are not conducted in open environment and learnings are not taken ahead.

6. Managers - Please dont delegate your tasks in name of Agile. Reporting, task allocation, project planning, risk planning, mitigation, margins, allocation are all still your job- your deliverables. A SCRUM Master and SCRUM teams can only help you in thought process and assist in giving inputs to performing the role. My first SCRUM implementation sufferred when manager went hands free of the responsibilities and retained more of an administrative role only. SCRUM Masters are hands on and are quick in tuning velocity needs to meet plans. Treat SCRUM Masters as navigators (Velocity Managers) and SCRUM teams are drivers (taking you to the destination). The project charter still is your responsibility, dear Manager.

To Developers:
1. Understand that you should now think modular. No longer quick codes that handle a job piece as stand alone program are going to work. While thinking, ensure you follow a modular structure. Think what pieces could be converted as a lib file, what could get into config file, what needs to be a third party extension, how you would create hooks, interfaces to move them further and how you could split the source code into multiple files in src folder.

2. Make sure you always make provision for 35% effect. 35% of your code will be tranformed - either scrapped or rewritten or extended or reused. Think and Design every code for this 35% rule. And this is critical to success of Sprints.

3. Estimate time including scrap value. This is why Sprints and SCRUM estimations are good. Since they are done by team members who are going to work, you can factor in time to experiement with your ideas for some time.

4. Think Design first. Papers and Pencils are still the best form to release creativity. Agile, atleast in SCRUM context doesn't mean you jump in to code directly. In fact, it is opposite to this thinking sense. Design, Paper craft your story, divide and define your tasks and then take up finishing a user story.

5. Do not assume or expect Product Owners to be techies. In fact as a product owner, the job is to define the vision, goal and the working way for a user. You, as a developer needs to help product owner visualize how it will look at end. Not the other way around.

6. Escalate. SCRUM Masters and Product Owners and even your peers are humans. They are bound to make errors. Own the stand up meeting room to yourself. Make sure you articulate the allocated story well. Ask your peers for impacts in their code. Check if there are dependencies. I have seen 2 kinds of stand up - One where SCRUM Master speaks most of time. Another where designers and developers speak their mind. You can guess which would be the most fun.

To Onlookers:

1. Support SCRUM, even if you dont understand it. You are making the environment more greener. ;)

2. Read Agile Manifesto.

3. Reflect and embrace change as constant. Controls and Measures no longer work. Measure only what is done, not fit measurement to what was designed.

4. Visualize: Figure out the ways how SCRUM would have tackled your problem. Visualizing SCRUM implementation or for that matter any process, will make you more resilient to make the transition against heavy odds.