Category: Agile Transformation

Myth about baselining the Sprint Lengths at the start of the project

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing the a contract – But like everything in scrum, the Sprint length needs to be open for Inspection and Adaptation

Common Misconceptions and negative implications

Most organizations and Agile experts implement Sprint Length as a fixed length baselined at the time of writing a SoW or a contract.

Recommendations

  • Scrum Guide recommendation is to keep the Sprint Length “Consistent”. Scrum Guide does NOT recommend a “Fixed” Sprint Length. We can change Sprint Length if there are negative implications being caused because of incorrect Sprint Lengths.
  • Considerations for changing the Sprint Lengths
  • Changing Longer Sprint Lengths to shorter Sprint Lengths (say 4 weeks to 2 week)
    • The scope keeps changing during the Sprint and Sprint Backlog becomes a mess. What we started off at the time of Sprint Planning and what we ended up in a Sprint Review is drastically different
    • Teams develop a “student syndrome”. Means – team takes it easy for the first couple of weeks. Then goes for a dash to the finish. The team then ends up working 18 hour days for last 2-3 days
    • The feedback is so drastic each Sprint Review that you need to re-work the whole thing. Think about the Sprint Length if this happens frequently.
    • Teams and PO don’t speak to PO often and communication breaks down resulting in no or minimal feedback during the Sprint.
  • Changing Short Sprint Lengths to Longer Sprint Lengths (say 1 week to 4 week)
    • Teams come under a huge stress. Deliverable every Friday is not easy. The stress levels take a toll and teams get sick of the stress.
    • Innovation goes down with very short sprint lengths. Teams become very “short-term” focussed.
    • Dividing items into smaller units becomes difficult. Beyond a point, breakdown of Product Backlog Items becomes a formality/academic rather than a real need.
    • Spilled-over work to next Sprint becomes common with very short sprint lengths. Teams are unable to create something useful.
    • Motivation goes down because of stress levels or not being able to get the Sprint to produce something usable every Sprint or stakeholders constantly feeling upset about not being able to complete.
  • DISCLAIMERS SO THAT YOU DON’T MIS-UNDERSTAND OUR STATEMENTS ABOVE
    • DO NOT keep changing the Sprint Lengths often. Try a Sprint Length, see if it works. If it does not work, then change. Once you find a length which is solving most of the problems, then stick with it. Be CONSISTENT. Being able to change the Sprint Length does not mean you become random and chaotic in the way you work.
    • DO NOT think that there is a “PERFECT Sprint Length”. There can never be a “Perfect Sprint Length”. See what Sprint Length solves “MOST” of your issues.
    • DO NOT change the Sprint Length when you are inside the Sprint. Just because you are not completing a Scope, does not mean, you change the Sprint Length by extending it. Sprint ends when a Timebox ends. You may think about changing the Sprint Length from the next sprint onwards.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-baselining-the-sprint-lengths-at-the-start-of-the-project/

Myth about Definition of Done being baselined before project starts

definition of done is often looked at a checklist that is set in stone-something not evolving – let us discuss how Definition of done evolves

Common Misconceptions and negative implications

  • Definition of Done is directly compared with Quality Criteria which was used in waterfall. Because of this teams tend to baseline the definition of done before starting the project
  • By baselining the definition of done, product teams and delivery teams don’t get to iterate the quality criteria as they go-along
  • Lot of time then gets wasted in trying to get the product too precise and the releases get delayed

Recommendations

  • Definition of done should be emergent. That means the definition of done should get more and more stringent as the product maturity increases.
  • There is no point in trying to make the Definition of done too stringent upfront. Instead one can always start with “the bare minimum” definition of done.
  • As the product matures, it is often necessary to make the definition of done stronger. It makes sense then to make the definition of done stronger as you go along.
  • However, one must understand that if the Definition of Done becomes stronger, then there may be undone work associated with the product and the product must be brought to the current definition of done. That means, all the undone work must be identified and put back into the product backlog.
  • For example : One could start with a definition of done as
    • Acceptance criteria for functionality is met
    • User Documentation is completed 
    • Integration testing is done
    • Regression testing is done
  • As the product matures, lets say, after 6-8 months, the volumes increase drastically and product becomes slow. Then it may be required to add performance testing into definition of done. So the new Definition of done could become.
    • Acceptance criteria for functionality is met
    • User Documentation is completed
    • Integration testing is done
    • Regression testing is done
    • Performance testing is done
  • So now one must understand that because Performance Testing is added to the definition of done, it is now required to add the “undone work” associated to the last 6-8 months of product that was already completed. And that means, we may have to dedicate some time in the upcoming sprints to get the product to the current definition of done.
  • By doing this, it avoids a lot of initial wait time before we get the product into the market. In the above example if we would have added performance testing initially, a lot of time could have been wasted trying to do performance testing when it was not required. We could have missed the window of opportunity. Our competitors would have released the product earlier than us.
  • It is not just the scope which is iterative and incremental in Scrum. Definition of done (Quality Criteria) is also iterative and incremental.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-definition-of-done-being-baselined-before-project-starts/

Myth about Scrum Master being a renamed Project Manager role

A commom question often asked – Can we treat the Scrum Master as “The Project Manager in Scrum World?” – Let us understand how the world differs

Common Misconceptions and negative implications

  • Organizations implement Scrum Master role by renaming all their Project Managers as Scrum Masters just because they want to do Scrum or try Scrum. Scrum Master is the most mis-understood role in the industry.
  • Scrum Master remains the same “Command and Control” role
  • Scrum Master is made accountable for Product Scope, Product Delivery, Product Quality, Product Budgets and Project Timelines. Management holds one neck and that is Scrum Master’s neck
  • Scrum Master becomes a coordinator as the Project Manager used to be

Recommendations

  • Scrum Roles are designed in such a way that the right role takes the right accountability. The Project Management was a centralized accountability model where Project Manger was made accountable for everything. Scrum is a distributed accountability model. The Product is owned by the Product Owner. So, the accountability of Scope, Cost and Time is given to the PO. The Developers is made accountable for the delivery. So, Quality is the accountability of the Developers. Scrum Master is the guardian of Scrum. He/she is a coach and facilitator who makes things happen by making the right role take up the right accountability.
  • As a Coach, Scrum Master is a leadership role who guides the PO and Developers into following the Scrum Framework. Scrum Master makes the PO, Development Team and the Organization aware of the self-organized model, cross-functional teams, product accountability, complexity handling, importance of timeboxing, tools, techniques – in general Scrum framework as a whole.
  • As a Facilitator, Scrum Master makes sure that focus on getting decisions done and progressing towards goal. Scrum facilitates meetings, communications and helps the PO and Developers to come to conclusions. Many a times, the delay in decision making is the major cause of productivity issues. People don’t come to conclusions. Scrum Master’s job is to get the people to conclusions.
  • As an Impediment Solver, Scrum Master reaches to the right entities of the organization and gets right help at the right time so that team can proceed.
  • Scrum Master is a Servant Leader whose job is “to serve”. The accountability of doing the product work is given to  the Product Owner and Developers. Since Project Manager is responsible for Scope, Cost, Time, naturally it becomes a “Command and Control” role. The leadership styles are completely different.
  • Scrum is based on the “Fail-Fast ” model vs the Project Management which is based on “Don’t Fail” model. Scrum encourages the team to fail and let the team learn from mistakes. Project Manager makes sure that as much risk mitigation is done so that mistakes don’t happen. Scrum Master’s job is to allow mistakes and let the team learn from mistakes. Project Manager’s job is to prevent mistakes. They are diametrically opposite in the thought processes.

With so many drastic differences, if the Project Managers are renamed as Scrum Masters, the way people think is no different than what used to happen in waterfalls. Naturally done, we are setting up things for failure if Project Managers are renamed as Scrum Master. Lot of training and mentoring of Project Managers is to be done so that the Project Managers think differently to what they used to do while they were project managers.

This article is re-published on WORLD OF AGILE website –https://worldofagile.com/blog/myth-about-scrum-master-being-a-renamed-project-manager-role/

Agile Metrics – Friend or Foe

how to create a Metric framework for for your Program – How to choose Agile metrics , How to derive value from your Agile metrics

Agile Metrics is an area that causes quite a heartburn for many agile practitioners. There are strong advocates on both sides of debate. Some people will insist that everything you can measure -you should measure. They will say “only what gets measured, gets improved” .. These people will insist that measuring our progress, helps us to keep on track , to see if we are working up to our potential. They also argue that Metrics help baseline and allow us to have cer

On the the other hand we have people who will have objection to this very “base lining” as they believe the comparison leads to people focusing on Metrics rather than value …They argue that metrics add overheads and often can be manipulated to paint a picture you want to depict. A heavy metrics framework goes against the idea of simplicity.

Both sides have got merit in their point of view. But fact of matter is Metrics are very much here to stay. Its up to us to set up metrics that are lean and still deliver insights. In this section I am going write a series of articles that describe how to set up such a framework. Some of the topic I am considering are:

  • Why Metrics Need To Be Different For Agile Projects? Do we really need metrics for our agile projects?
  • What Metrics are seen to help agile projects?
  • Some Pointers to keep in mind while defining metrics for your projects

Of Course Metrics can never be defined in isolation – they need to be thought in context with your contracts as well as your own scrum implementation.

Benefits Of Agile :: They may not be what you think.

We all know, Agile transformations can be incredibly painful…. In this article I want to explore why organisations are taking that pain. What are the benefits that organisations get by going agile?

Ask any organisation newly starting their agile journey, and they will say they expect time to market & cost to improve. In reality, the project duration of an increases because of the constant changes. Similarly execution cost is not always lowest agile, constant inspection and adaptation does have an overhead associated with it. Then what then are the benefits actually obtained by going agile?

Let us take a look at the some findings from 13th version one survey . This survey polled multiple stakeholders across geography, project type and associate seniority. 

We can see from the image above that, nearly 70% people find that rather than cost or time ti market, agile is helping them manage the changing priorities. In my eyes, this is the greatest advantage of agile bring to the table. Priorities are handled efficiently. The end users receive the features they want at a faster rate. This gives the feeling that time-to-market has improved.

Similarly, an Agile project encourages user requested features rather than the plan driven features. Because of this the team develops features that the users want.

Most organizations transitioning to agile see Improved quality. By definition an iterative process lends itself to better quality. More ever agile puts the focus of quality where it belongs – on the development team. This ensures that sub quality deliverable does not escape.

Better quality coupled with getting the features that the actually want leads to better end user satisfaction and indeed we should be the most important success criteria for any project!

Agile brings predictability. Management is usually happeist with this one key benefit. Delivery in a Cadence helps the management to know when the next feature is being rolled out. With prioritized execution, management can be sure that at any given point for a given cost the most important features would be implemented. 

Last but not least, agile helps with employee morale and job satisfaction. Ajay sports the development team in control of how the development is being done. This means employees now have the ability to self organise , they are empowered to take decisions and have more control over their working life. This increased control along with the emphasis paid on sustainable development mean that employees are now more engaged and more happy. Lofty goal for any organisation.

Agile Transformation in An Agile Manner :: Form an Agile Team

Transforming the way of work to agile will be a one most effort consuming work your organization will take up. The team composition and roles need to be well thought out to ensure relatively smooth transformation. (The work anyway will be volatile enough!). Some of the key criterion to keep in mind while forming teams are

  1. Members who have influence – For a change that is all pervasive, it is important to choose stakeholders who can influence the change
  2. Members Who Are Excited – Having members who are excited about the change will make the initial part easier
  3. Diverse Skills Scrum is pervasive. So to adopt scrum we need changes in organizational process , technology , org structure , skill building – its essential to have people who can manage these diverse areas of impact
  4. Have a Sponsor – Choosing a sponsor who can not only influence but is also actively engaged with the team.He should be the leader who is engaged enough that he encourages others to be drive. Some of the most successful agile transformations have the sponsor as a product owner. This then ensures that his vision gets implemented. 
  5. Consider Chapter teams – Chapter teams are the horizontal teams who take up a specific item on the backlog and then drive it through the organizations. They usually end up having a sub blog for their own area of improvement.We discussed this sub log structure in earlier post
  6. “Two in a Box Coach team” At times it is helpful to have a combination of coaches – Internal and External coaches working together. External coaches are able to bring outside perspective and they are in a better position to influence senior management in their capacity as “expert consultant” . At the same time, internal coaches are better able to understand pulse of organization and carve out action items that actually work 🙂

Driving an Agile Transformation in Agile Way :: Build a Well Planned Product Backlog

Like every scrum project, an agile transformation needs to have its own Product backlog. This backlog will list all items that need to be accomplished in order to transform organizational way of work to agile.

Some Key Items to consider

  1. Consider using backlog with parent child structure – Agile transformation is a complex piece of work. In the initial stage all the items identified will be very large in size and each of those then needs to be decomposed in items that are manageable in size. Often the top level items are quite independent in nature and will be executed by different sets of people in your organization . For a recent transformation I was a part of some of the initial items in the backlog were Increase Scrum awareness ,Create a supporting organization structure that enables scrum and Increase automation . Each of these items needed to be implemented by completely different teams. Managing the backlog was becoming a difficult task and we ended up creating a sub backlog for each of the items in the parent backlog
  2. Ensure that each item has a defined/measurable acceptance criterion. For any large initiatives you will have negative stakeholders – Those stakeholders who are skeptical and don’t agree on value brought in by the transformation. It then helps to have measurable success criterion – defined and agreed upon before you start the work.
  3. Deliberate on Business value of each item – With stakeholders and team members being used to a plan driven way of operating, the product backlog transforms into action driven plan rather than a list of items where each item adds a discrete value. It helps to consciously call out the business value attached with each item. Over time this becomes a habit but it needs attention and focus initially while the team is getting used agile way of working

Driving an Agile Transformation in Agile Way :: Plan Short Sprints

As we discussed before, many of agile transformations start with a detailed, prescriptive plan mandating action items…..This a beautiful plan considering a lot of perspectives, it is rarely a short plan! This does not allow stakeholders to realize the value that is delivered. As a result after a while stakeholders, most of whom already have a lot of responsibilities start to get the dejected…

A good to way to conqueror this can be to design the transformation as a series of sprints which together deliver the large enterprise goal, but each sprint individually delivers at least a small, tangible piece of that large goal. These smaller goals allow stakeholders to taste success and retain their enthusiasm. It also helps to spread the word and convince those who are on fence.

I usually suggest that these sprints follow the scrum events and artefacts. It allows the team to collaborate in a structured manner. I have found that often stakeholders who are worried about one more topic for long meetings. They are really happy at the prospect of one short and time boxed meeting everyday. Once they see the benefits of shorter sprints , timeboxes and demonstrated values, they become the biggest supporters. In fact the opposing party stakeholder I mentioned in earlier article, went on to be the biggest agile champion in that organization.

For this short sprints to succeed its really important to have goals that can be measured and have a product backlog that is well refined. More about that in my next post…

Driving an Agile Transformation in Agile Way :: Defining a Concrete Business Value

Many organizations today are trying to start an agile transformation just for its sake. Its almost like that they are afraid of being left behind. Some stake holders perceive agile as a “compliance” activity that they must do in order to clear some audits.In fact, in one of the projects, one of the senior VPs told me “Ma’m all this agile and stuff is just a new name for the same old thing. It wont solve my problems“…. Many of us have come across this resistance when people don’t perceive any real value to them by going agile. They believe “we were delivering projects before, we will continue to deliver projects … how much difference a mere ‘way of work’ can bring?”

I have had some of my most notable successes, when I shifted the focus away from agile structure -( the events, artefacts and rules) to agile values and principles. I ask the stake holders a simple question “List some of your pain points in current way of project execution” Almost everyone has a long list of items that they claim are painful. I then move along further – In an ideal world – how these painful items would change? After I manage to do chip at the usual reluctance, we get to the meat – people start listing out things that they believe will help. Now we are in business. We then identify items that will bring most value to the organizations. These then become the value objectives for the transformations

Some points to keep in mind are

  1. Make sure that the items you identify, are adding real value to stakeholders. Its easy to have items that describe the behavior and not the result. We all are conditioned to track progress based on activities completed not results achieved . For example “code review done” is a behavior – the value can be “zero defect production release”
  2. Make sure the items on the list can be quantified and you agree on measurement criterion before hand. “10% improvement in time to market” is a better objective than “reduction in delays”

When the stakeholders see that their problems, the real problems are getting targeted, they are more open to change and having stakeholders who are at least open to ideal of a change is half the battle won…

Its important to keep the interest of the stakeholders, otherwise they lose interest quickly. Short sprints that show at least some measurable results is the best way to keep their interest alive and kicking – more about that in next post. Watch this space!

Agile Transformation in An Agile Manner

A lot of organizations these days have a grand plan to for their agile transformations. They hire “change consultants” , do a “OCM analysis” and come up with a detailed, prescriptive plan that they intend to track meticulously to completion. This in itself sounds so very “waterfallish”. To me it sounds like an oxymoron to have a plan driven transformation to make your organization agile…

In my experience as scrum master as well as an agile coach, a plan dictated approach usually does not work for to transform an organization to agile ways of working.This in no way means that agile transformation does not need planning, indeed it does but the plan needs to be flexible and driven by value delivered. In short, its best to drive an agile transformation in an agile manner.

Key aspects to drive the agile transformation in this way are

  1. Have the transformation focus on business value – Many organizations are starting the transformations, just to get on agile bandwagon. They have no idea why they want to be agile or what they will gain from being agile. These are the transformations which will fail most likely because there is no clear goal. It is important to have a clear idea about what business objectives will be achieved by being agile.
  2. Plan Short “Sprints” – Rome was not built in a day and often the transformation plans are detailed, prescriptive and long term. They do not have a tangible value that gets delivered sooner rather than later . This in itself contradicts the agile principle of ” Early and Continuous Delivery  ” I have found it very helpful to divide the ultimate transformation goal in smaller , more immediately achievable sprint goals that can be demonstrated to stakeholders. This also helps to build consensus and create a positive vibe about the whole initiative
  3. Build a Well Planned Product Backlog – While its easily said to have short sprints with sprint goals that are achievable and can be demonstrated, its another story to actually identify those goals. For that it helps to build a prioritized and refined backlog to achieve the business value that is desired. This refinement is ongoing and usually tests the facilitation skills of the scrum master.
  4. Form an Agile Team – Like any other project that we do, transforming an organizational way of work to agile is a complex and challenging work. It needs all the 3 roles of a scrum team. A scrum master who is experienced. A product owner who can articulate the value and represent it in the backlog. Last but not least, we need a development team that actually implements the backlog items.

Each of the aspect mentioned above deserves a post of its own – there is a lot be discussed. I intend to do just that and write in detail about my perspective of agile transformation in the time to come. Stay tuned!