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.

Focus on Commitments than planning for Schedules

Communicate commitments proactively and follow up on the commitments to showcase it is done as per the plan. That is the secret of great project successes and basic expectations of all clients worldwide.

Commitments are misunderstood by many including managers as creating elaborate Gantt and plans and tracking the happennings to plans. Yes, these are required for many reasons. Understand cost, complexity, schedules, audits, controls, risks, etc. It gives a holistic view on whether the revenue earned is profitable and plug the leaks in the system to maximize gains and invest more in better customer experience.

But these grand scheme of things are not close to what commitments can do for client and your business leaders.  What is valued much is a delivery arriving at a planned and pre-communicated date. Making it a habit to ensure constant flow of deliveries at set future dates that are consistently proposed in advance is what commitments are and symbolizes great working practices. In short milestone after milestone we just to need to keep sharing the dates in advance and release at the pre-committed date to gain trust and premium worthiness to our service portfolio.

If you notice, in actual projects, plans and schedules get adjusted to the actuals and those planned dates serve to analyze the differences with the acutals for next projects. The plans serve to improve predictability over a period of time. It is a common understanding that plans exist to be scrapped and redone as the work unfolds and new players, deliveries get produced that alter the environment to deliver.

Commitments need to always come from grounds up. People on the field say they will deliver the desired scope in the given time. As long as manager keeps the course by keeping themselves out of the way and work towards clearing the impediments in the paths for working professionals, the commitments are bound to be met.

Clients are happy hearing from the actual field people on the feasibilties, risks and dates with inputs from managers than gloss over presentations detached from the actual workings.

Commitments need to always be near term. Because this is the only specific that can be controlled and managed without interferences and distortion and thus can be met.This is quick, transparent, visual and tangible. More frequent the positive feelings, better is the perception and experience.

Commitment messages are understood nearly the same by every one: "I am going to get it, I am getting it and I have always got it." Semantics to this may wary, but the messaging is consistent, clear and harmonious throughout all stakeholders and without ambiguities.

This is what Kanban and Sprints in SCRUM help you achieve. Kanban helps people in ground share the status visually. Sprints focus on delivering near term goals and scope. Both Kanban charts and burn down charts show case the ability of teams to deliver on commitments and impediments crossed to deliver them.

Believe me, making a project successful is not rocket science. But it is utmost difficult because of lack of commitments and over relying on past plans and practices. These can easily be overcome with little discipline of tracing Kanban charts daily and meeting daily to share and exchange workloads, dependencies and learnings.

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.