Tag: scrum

Benefits of using Scrum [over waterfall]

Agile is probably the best approach when it comes to developing complex IT solutions. It’s widely used in product development, but unfortunately, it’s still not that straightforward when you’re working for external clients. The problem is that in far too many situations it’s the corporate purchasing department that awards the seller with a contract, and fixed-scope, fixed-time and fixed-schedule is the only solution you can pitch for and count on.

The good news is, however, that in many cases there is a place for negotiations and you can have a chance to present your vision of how the project should be delivered. You won’t probably end up in a T&M agreement, but you can have a chance to agree on the model that would enable you to benefit from using Agile and talk the client into some adjustments to the process.

I was personally involved in several discussions like that and I think that the most important part of your presentation is to concentrate on how the client can benefit from using Agile and what are the main advantages of Agile over traditional waterfall approach. It’s not the time for describing details of the framework, it’s your chance to present some convincing and easy-to-understand-at-first-glance slides that would hopefully result in awarding you with something better than fixed-scope, fixed-schedule and fixed-price agreement.

Below please find a compilation of slides that I used in some of my presentations, and that shows the advantages of Agile over waterfall approach. I hope you’ll find them helpful.

Link to SlideShare

 

Tracking progress of the release

Having a potentially shippable product every sprint lies in a heart of Agile, but in many organisations – especially the ones that don’t work in SaaS model – a product is not released to the market every sprint. Sometimes frequent delivery is not possible (i.e. in case some additional tasks like a translation of a documentation, legal approval, etc. have to be done at the end of the release) or it’s not even desired. What happens in such cases is that delivery to the market is organised in some more or less formal releases that are shipped every couple of months (internal releases can be still more frequent, though). Working with releases doesn’t require almost any extra efforts, but still, it usually involves some additional activities like release planning and requires for tracking progress on a release level.

Tracking and adapting to changes on a release level becomes particularly critical if release goals are directly or indirectly bound to some marketing or sales activities that require some up-front planning and synchronisation. Fortunately, tracking release progress is not a rocket-science and most software tool that are available on the market support this functionality. JIRA, the tool that I’m familiar with, provides you with 2 simple reports that you can use at easy.

Version Report

Version Report shows your progress towards completion of a release (estimated work). It uses average velocity and estimated amount of work remaining to predict a forecasted release completion date (a date when all the estimated issues in the release are estimated to be completed). In addition, Version Report can be also used to monitor how a scope of the release has been changing since the start of the release which can be a useful tool for checking if release planning was valuable (great input for adaptation and team’s retrospectives).

You can read more here: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/using-a-board/using-reports/viewing-the-version-report

Release Burndown

Release Burndown report shows how you’re burning story points of all the estimated stories that were planned for the release. It uses average velocity and estimated amount of work remaining to present a predicted number of sprints that are required to complete the release. Release Burndown report presents information on per sprint basis and therefore it can be used to track how much work was added, completed and left remaining in/after each sprint.

You can read more here: https://confluence.atlassian.com/agile/jira-agile-user-s-guide/using-a-board/using-reports/viewing-the-release-burndown

 

Splitting large features into smaller stories – Elephant Carpaccio

Many teams transitioning to Agile struggle with delivering a potentially shippable product every sprint. Producing a piece of software that provides a business value to a client every 2 weeks seems impossible. Usually, teams say that they can deliver either front-end, or backend, or architecture design for a given feature, but not all these together.
It’s a common problem for many teams that are new to Agile, but my experience shows that it’s also a problem for more mature teams that prevents them from advancing to the next level of agility.
Why is that? IMHO it’s because many teams struggle with a concept of delivering software incrementally and they are much more focused on an iterative part of Agile paradigm. They struggle with understanding that larger features don’t have to be implemented in one chunk and that they can be built in several steps. It usually means that a given feature won’t be perfect from the very beginning, but it doesn’t have to be! It’s one of the key concepts of Agile – deliver value incrementally, wait for client’s feedback and adapt accordingly (if need be).
Many developers say that they can’t split a given feature into smaller chunks not because they are not capable of doing so, but because from their perspective something less than a whole feature is imperfect, non-functional and not worth presenting to any stakeholder.
It may be a huge problem because it influences planning and tracking & monitoring, and therefore impacts transparency and works counter short feedback loops. Improving it requires changing the mindset and adjusting way of thinking which is never an easy process.
The good news is that teams are not doomed to fail here. First, they learn how to split larger features into smaller chunks as they progress with Agile and gain more experience. In addition, Agile itself forces them to do so because there is nothing more embarrassing than holding a sprint review and having to explain to stakeholders that there is nothing to present and discuss.
In addition, it’s possible to encourage the right approach by doing some exercises with the teams. One of them is called “Elephant Carpaccio” which I hope you’ll find useful. It was originally proposed by Alistair Cockburn and you can find more details about it here.
I executed this exercise with my teams and I must say that the results are quite promising. Of course, there were a lot of discussions and complaining, but overall people liked the idea and said they learnt something from doing it. Pretty much everyone agrees it was a challenge to split an application they would deliver in 1 hr into 20 small user stories, each of them of a meaningful value to a client.
If your teams struggle with splitting large features into smaller stories I recommend doing this exercise with them. It’s bit “artificial” but should result in some fun and good discussions afterwards.

Inter-team Commitment Stories

Managing complex and lengthy projects is a challenge. When dozens of people are working on the same product in parallel there has to be a mechanism for identifying and resolving dependencies and cross-team blockers.

In traditional projects, it’s a PM’s task to ensure that all the team members are working on right tasks in right order. She is the one who decides about priorities, monitors progress and initiates corrective actions when required.

In the Agile world, there are self-organising teams that are accountable for delivering outcomes they committed to. There is nobody who defines how the work should be done or what actions need to be taken. Of course, there is a Product Owner who sets priorities, but there is no direct mechanism for synchronising work between various teams.

There are several frameworks (i.e. Scaled Agile Framework or Nexus Framework) for scaling Scrum that provide some solutions for managing complex product development efforts, but still it’s up to the teams how they self-organise around managing project dependencies.

A solution that can help resolve a problem of managing dependencies in complex Agile projects is a mechanism called Inter-team Commitment Story (please refer to Agile Project Management by Jim Highsmith).

Inter-team Commitment Story (ICS) is a form of a story that works as an agreement between two or more teams. It’s a kind of a contract that defines set of responsibilities on each party’s part and specifies what and by when should be delivered to get the dependency resolved.

ICS may be somehow overseen by an integration team or project leader (they can be the ones to identify the dependencies in the first place), but it’s teams’ responsibility to mutually agree how a given dependency will be handled. Of course, it’s also Product Owner’s responsibility to make sure that Inter-team Commitment Stories are prioritised accordingly and that a pressure to deliver business stories doesn’t make some teams blocked.

Inter-team Commitment Stories are planned and scheduled as all other stories in the product backlog. And most of all, ICSs are estimated so that the cost of managing team-to-team coordination is not hidden. The main advantages of this mechanism are:

  • dependency management and coordination work are visible,
  • it downgrades the coordination from project manager to teams that know the details,
  • it helps to build accountability,
  • it supports inter-team collaboration and builds cross-team relationships.

 

Limiting Work in Progress

In many organisations being busy is valued more than delivering the results. At first sight, it may sound quite reasonable – after all, we’re all paid for having hands full of work, aren’t we?

Unfortunately, it doesn’t work that way. In a vast majority of cases, the more tasks we try to complete, the less we really accomplish. And pushing yourself to work even harder doesn’t change anything.

Why is that?

The scenario described above is quite common for many teams and it’s usually caused by an excessive Work in Progress (WiP). WiP is anything that is started but not yet completed. It’s a User Story that was started, but hasn’t been Done yet – it’s either blocked, or awaiting QA, or resides in any other halfway state.

Excessive Work in Progress is harmful for several reasons that, among others, include the following:

  • It leads to mistaking activity to accomplishing valuable work.

Limiting WiP introduces slack time which is regrettably not acceptable in far too many organisations that blindly follow “100% utilisation” approach. The truth is that fair amount of slack time is desirable; it happens when any team member, for whatever reasons, is “blocked” because of WiP limits and cannot do regular work. I’ll cover slack time and 100% utilisation myth in a separate blog post.

  • It diverts our attention from what’s of the highest priority to less important tasks.

When we get blocked it’s much easier to move on to something else rather than bend over backwards to get an original task or blocker resolved. Unfortunately, in most cases it implies an implicit, ad-hoc prioritisation instead of following an original order of work (after all, an original task was of a higher priority – otherwise you wouldn’t be working on that, right?).

  • It’s exhausting mentally.

Please bear in mind that anything you have started but not finished occupies some part of your available mental capacity. And the more WIP, the more mental energy is consumed with trying to keep track of it all. Although one can argue that even with many tasks started people work only on one of them at the time, unfortunately, it’s not true – Zeigarnik Effect suggests is that our brains will be switching context despite what we consciously think it would do.

  • Context switching is a cost.

Context switching prevents us from getting into flow which is a key to being highly productive. Usually, it’s exemplified by talking about distractions and interruptions (instant messages, phone calls, etc.), but having too many tasks in progress causes the same problem – it works counter to flow. We’re most efficient when allowed to complete one thing uninterrupted. Switching between tasks requires context change and it takes time we need to get at full speed back again. Multitasking  harms our productivity.

Now, as you know that Work in Progress should be limited, the question arises how it can be achieved? The solution may differ from team to team, but the common idea is to disallow to have more stories in “in-progress-like” status (In Progress, Awaiting QA, Awaiting Code Review, Blocked, etc.) than an upfront agreed threshold. It basically means that none of the team members can take on a new item if a given number of tasks are already being processed.

This approach is usually backed with a simple guidance that whenever you finish work on an item you should check if there aren’t any unassigned tasks starting from the rightmost part of the board (that’s closest to the Done column). And you either pick one or you move one column to the left (towards To Do column) and keep repeating the whole process until you find something to work on.

Agile is not about being busy, but about delivering value to the clients. Delivering it fast to foster learning and outperform competitors. And Work in Progress limits encourage a culture of “done”. Moreover, WiP limits make impediments, blockers and bottlenecks visible and enable the team to swarm around them to get them resolved as soon as possible. WiP limits smooth the flow and increase overall team’s productivity.

So, please stop starting things and start finishing them!

 

Agile Assessment

Many organisations and teams that adopt Agile come to the point where knowing how agile they are becomes an important question. It’s especially important when first stages of Agile transformation prove to be successful, teams finally work at a sustainable pace and it becomes more difficult to identify obvious areas for further improvements.

There are many agile assessments available (please refer to a great blog post by Ben Linders), but none of them fit to my needs 😉 and therefore I ended up creating my own evaluation. It’s grounded on an assessment presented by Dean Leffingwell in Scaling Software Agility:Best Practices for Large Enterprises, but I made several adjustments based on my experience from working with various Agile teams and projects.

The assessment is a great input for the team to improve. Moreover, if you have more Agile teams working together, the assessment can be a vital source of information for Scrum Masters and management that should enable them to work on organisation-level impediments preventing the teams from working even more effectively.

The assessment consists of 66 statements/questions grouped in 7 areas: product ownership, agile process, team, quality, engineering practices, fun & learning and integration. Every team member should assess each statement using a scale from 1 (the worst) to 5 (the best). As a result, you get an average assessment of each statement for the whole team and resulting evaluation for each area. The latter is used to plot a Radar Diagram that graphically presents the results.

Please be aware that there is no single, correct interpretation of the assessment’s results. It’s something that very depends on your organisation, maturity of the team and people you’re working with. Furthermore, it’s not final values that matter the most, but their relative comparison and how they change over time (progress/improvement).

Feel free to download the assessment and adjust it to your needs. Please don’t hesitate to let me know if you think that some changes should be implemented.

Download Agile Assessment Download the Agile Assessment spreadsheet

Relative Value Points

Product backlog should be DEEP – detailed appropriately, emergent, estimated and prioritised. Everyone who learns about Scrum should be familiar with these key attributes of a good product backlog.

But how is the product backlog ordered? Well, most Scrum practitioners would probably say that it’s Product Owner’s decision, but the business value seems like a fair attribute to be used for product backlog prioritisation.

While saying so is a good generalisation the reality is, unfortunately, a bit more complex. The reason for this is that a good product backlog consists not only of client-facing stories, but there are also other items like design spikes, technical debt reduction stories, maintenance items, etc. Smart Product Owner knows that she can’t concentrate on business stories only because she’s responsible for long-term product’s adaptability and reliability.

In addition, things like upcoming marketing event may also drive prioritisation and, therefore, short-term value and features of a lower overall value can take precedence over long-term gains.

Furthermore, risk mitigation is also a very important factor that influences how product backlog is ordered. Actual risk reduction is a key objective that the team should concentrate on at the beginning of a complex project. For example, it makes sense to prioritise some technical stories first to check if a technology we want to use is right the project before investing too much money into an endeavour that may eventually fail.

As you can see ordering a product backlog is an act of balancing many different factors, and although business value should be the main driver other aspects also influence decisions made by a Product Owner. It’s worth remembering that there is a difference between value and priority.

OK, but how does a Product Owner know a business value of all the stories? Of course, it’s a Product Owner’s job to understand what set of features the product needs to have to delight its users, but how does a Product Owner make day-to-day decisions when a product backlog consist of hundreds or thousands of items? Relative Value Points (see Agile Project Management by Jim Highsmith) and ROI is the answer.

Value points are somehow similar to story points, but they are calculated top-down instead of bottom-up. The idea is that value points (i.e. 1, 2, 3, 5, 8 and 13) are assigned to features first, and then a percentage of total feature points is calculated for each feature (i.e. three features with 3, 5 and 8 value points assigned get 19%, 31%, and 50% respectively). Next value points are allocated to stories (the same way), but the percentages assigned to a set of stories are capped by the percentage of their parent feature (i.e. if the first feature consists of two stories with 2 and 8 value points assigned, the percentage for these stories is 4% and 15% respectively).

As a result of using this simple algorithm all the stories in a product backlog have a percentage value assigned. A value of each story is relative to other stories and, therefore, allows for comparing them with regards to a business value they deliver to clients. Relative value points can be further used to allocate revenue stream or net present value (NPV) to features/stories, but most organisations don’t go through this step (many organisations don’t do a good cost-benefit analysis at all).

Value points have another advantage – they increase transparency and understanding in the team. They can be also used to calculate a relative ROI (Return On Investment) for each story which is another tool that can help the team make better decisions regarding priority of backlog items. In this scenario, relative ROI can be defined as a ratio between the business value of a story (in value points) and its complexity (in story points). Please bear in mind that relative ROI can’t be converted to money, but allows for comparing user stories – a chart below can help Product Owner see which stories have best ROI:

relative value points

 

Good Retrospectives

Overview

Retrospective is one of the inspect-and-adapt opportunities provided by Scrum framework. It’s a time-boxed event for the team to analyse their way of working and identify and plan potential improvements.

Sprint retrospective is one of the most important, but probably also the least appreciated practices in the Scrum framework. Therefore, retrospectives have to be carefully taken care of because inspection and adaptation lie in the heart of agility. It’s an important mechanism that allows a team to continuously evolve and improve throughout the life of a project.

Atmosphere

Sprint retrospective is a time to think about the process and practises hence the full Scrum team has to attend it (including Product Owner and Scrum Master who facilitates the discussion).

Assuming trust and safety are in place, everyone is encouraged to be completely honest and reveal all difficult issues one has in mind. Team members are expected to present their opinions in an open, genuine, yet constructive atmosphere. It’s facilitator’s responsibility to ensure that discussion stays positive and professional, focusing on improvement of the team as a whole. It’s critical for retrospectives’ long-term success that finger-pointing, assigning blame and personal criticism is absolutely avoided.

Quantitative Assessment

Before you jump in into a hot discussion some reporting of important metrics should be done. It’s required to set a context for the discussion and objectively present how the team has performed.

There is no one-fits-all set of metrics you should be using – they very depend on the business context, stakeholders, project, etc. However, it’s the team who should come up with the metrics they want to use to monitor and improve their work.

Last but not least, please bear in mind that whatever you finally produce it shouldn’t be static and set in stone forever. People and teams get used to their own measurements therefore, it’s good to try something else after a while. Replacing your metrics not only helps you cover other perspectives and uncover different unknowns, but it also keeps stagnation from creeping in.

Apart from velocity, risk assessment and product quality assessment the metrics you can use may include:

  • # stories
  • # stories accepted
  • % accepted
  • # stories not accepted
  • # stories added
  • defect count
  • # new test cases
  • # new test cases automated
  • % test cases automated

Qualitative Assessment

Retrospective, though important, is not a heavy-weight ceremony. It’s an open discussion that should include three main questions/points to address:

  • What went well during the sprint?
  • What went wrong?
  • What can we do differently to improve our work?

All the improvement ideas identified in the brainstorming session should be noted down, but not all of them should be immediately converted into real actions for the upcoming sprint, though. It may sound disappointing for some team members, but they need to remember that delivering value, not improvement itself, is their primary goal. However, since iterations are short, over time, all the issues will be finally addressed (or replaced with new findings during next refinement).

Actionable commitments

Identification of actionable commitments is the key to successful retrospectives. Open discussion is desirable, but in the end, some well-defined actions have to be agreed on. And the word “actionable” is significant. Actionable commitments are well-understood by the team, have clear steps to completion and acceptance criteria, just like good stories.

Let’s have some fun

The way retrospective meeting should be held is not pre-defined. There are numerous techniques for conducting retrospectives and none of them is objectively better than the other.

To be honest, trying different constructions of the retrospective meeting may keep things fresh and interesting. After all, team’s engagement is critical for a retrospective to succeed. Some sample techniques can be found here: http://retrospectivewiki.org/index.php?title=Tools

Personally, I remember a retrospective where “Draw a problem” approach was suggested by the Scrum Master and it was a great success. The project was depicted as a ship where good things were like a wind blowing sails while bad things were showed as an anchor that prevents the ship (team) from sailing faster.

Potential problems

Retrospectives are critical for the team to improve, but they need to be run correctly to make it happen. The team has to see real benefits of spending time in retrospective meetings.

Some typical smells that retrospective is not effective may include:

  • team members not attending retrospectives
  • unengaged attendees
  • no resulting actionable commitments
  • finger-pointing and assigning blame
  • lack of trust
  • complaint sessions and no desire to improve

The most demotivating and frustrating problem, however, is the team failing to follow through on improvement actions identified during previous retrospectives. It makes the meeting waste of time with no real impact on day-to-day work. The team has to understand that commitments they make matter and have to be met.

There is no silver bullet to address the issues mentioned above, but it’s Scrum Master task to realise that retrospectives are ineffective and work towards addressing issues like these. And if the team is new to Scrum inviting an external facilitator to conduct the meeting is highly recommended.

Edit: A great source of restrospective’s fun: How to Make Your Retrospectives Fun

 

Managing Product Adaptability

Overview

Creating reliable and adaptable software is not straightforward even if the team embraces Agile practices. In most cases, however, it’s not lack of technical capability or poor performance that prevents the team from achieving this goal. My experience says that the teams are aware that constant refactoring, automated tests, design spikes, etc. are required to keep the system reliable and adaptable – it’s senior stakeholders that usually fail to understand it.

Market is very demanding nowadays. Industry after industry demands for continuous innovation. Pressure for frequent releases and responsiveness to constant changes grows. And Agile seems a good solution for software teams to deliver valuable, high-quality products quickly. However, they need to be quick but should not cross the line and make mistakes. They “need to be quick but should not hurry“.

And unfortunately senior stakeholders far too often adds to this pressure and sacrifice long-term gain for short-term wins. Unreasonable deadlines are set and all the features are requested to be delivered. And in most cases the team manages to do that – velocity accelerates and the team delivers what they were asked for. But it’s a false acceleration, because corners are cut. And adaptability is the first thing that suffers from such an approach. Technical debt grows quickly and accumulates.

technical_debt_accelerated_velocity

Technical debt

Technical debt is invisible, especially at first sight and in short-term. Software is being delivered, features get implemented so why to bother about it at all, right? What really suffers, however, is system long-term reliability and, most of all, adaptability, but it usually doesn’t come to light quickly. But it’s a real problem that in long-term results in dropping velocity, increased cost and time to delivery, growing number of defects, and above all decreasing customer satisfaction. The company is no longer ready and able to deliver valuable software and adapt to tomorrow’s client needs.

technical_debt_coc

It’s especially frustrating from team’s perspective, because – if you ask them – chances are that they will directly mention parts of the code that need urgent refactoring and that contribute to technical debt the most.

Product Quality Assessment

This being said I suggest that one of the measures you can use to monitor if system’s adaptability is not deteriorating [too fast] is Product Quality Assessment performed by the team:

reliability_adaptability_assessment

This measure depicts team’s sense of the project’s “feel” (“smell” as called in XP). It can be supported by a chart that plots growth of the test code compared to executable code over iterations (both should be growing proportionally).

Why, in my opinion, this measurement is so important when there are dozens of other KPIs available? It’s not to say that it’s the most important KPI you should use, but it’s a canary in a coal mine that gives you an advanced warning of system adaptability potentially going down before other measures notice it. It gives you a chance to have a closer look into the problem before velocity drops, number of defects grows and the cost of getting rid of technical debt becomes [too] high.

Managing technical debt

Please be reminded that technical debt, like financial debt, has to be managed. It’s important to realise that there is no debt-free product, but you should be aiming at keeping technical debt low so that it doesn’t affect future product development. There are several possible ways of paying technical debt back, but the most important thing to remember is that it should be done regularly and incrementally. You need to avoid large balloon payments as a means of servicing technical debt when it’s far too costly, frustrating and time-consuming. By using some simple measures you can make technical debt visible – both to the business level and technical level. And hopefully convince everyone that technical quality is critical to achieve long-term goals and it shouldn’t be short-changed for current needs. Continuous value generation should be viewed from a whole product life cycle perspective after all.

To be fair, it has to be noticed that technical debt is not bad by definition – it just has to be acknowledged and managed properly. There are situations when technical debt doesn’t need to be paid back, i.e.: product nearing end of life, throwaway prototype or product built for short-life.

Please bear also in mind that technical debt can be intentional, i.e. when a fixed deadline has to be met. However, rather than being hidden it should be well-thought-out decision. The decision that not only allows for technical debt, but most of all acknowledges the consequences of introducing it and involves a concrete plan for getting it paid back in future. Otherwise it would be living a lie and asking for trouble.