Tag Archives: Agile software delivery

Agile Reporting at the enterprise level – where to look? (Part 1 – Status reporting)

4 Replies

In this week’s post I will talk about a topic close to my heart. How do you manage Agile projects if you have some scale. And especially how do you report on progress and use the lessons from your projects effectively across the enterprise? Let’s start by looking at what we want to get out of the reporting.

What should a good report show you:

  1. How has the scope changed over time?
  2. How much scope have we successfully completed?
  3. How is the team progressing towards the goal over time?
  4. How are we doing with cost?
  5. How is this team progressing compared to other teams?
  6. Which teams should I help to get them back on track? 

So here is the first example of a “traditional” Agile release burn-up that gives us information for points 1-3:
burnupSo how do you read this report? The first line shows how the target scope developed over time. In this case you can see that the number of story points required moved a bit up and down as stories were delivered. This is pretty normal for an agile project, nothing to worry here. We have an ideal line to show us what the “ideal” amount of accepted story points would be, of course no team ever delivers according to this line. If they do, I would ask a few questions as it just looks too good to be true – perhaps we bend the truth a bit in those cases to not explain the difference…

The actual burn-up and the predictions that the team tracks let me to the conclusion that this will be close, but that they can make it. This is a team I will keep an eye on going forward to see whether they catch-up as predicted. As the overall trend of total scope is also slightly downwards, there is a chance that the trend continues to a number even below 911 story points, which would be good for this team. 

Challenges with Agile reporting (points 4 & 5) 

If you are like me and are working in an enterprise environment it is likely that your teams use different iteration schedules, don’t have an aligned story point structure and are of different size. If you look at the release burn-up graphs, you can hardly compare them and by looking at many across the enterprise you don’t necessarily are able to compare their progress. Here is where my favourite report comes in – the relative burn-up that answers point 5 from our list of requirements.

relative burnupThe beauty is that you can show all kinds of things on this graph. In the example shown here, we track the progress of accepted scope against the budget (point 4) that we have used (and yes we are falling behind, looks like we need more budget to deliver our scope). Of course you can do the same for scope vs. schedule. And because these reports are relative to 100% of scope, budget or schedule you can now compare your status reports across teams. We are all aware that status is not linear and that the ideal line is mostly to be ignored, but if after the release has finished you look back at the teams that were successful and those that had challenges you can look for patterns. What percentage of scope did successful teams delivery after 50% of their schedule? How much budget did they have left after they completed 90% of the scope? Through this insight you can develop a portfolio view that I describe later.

One of the biggest challenges: How accurate is the data

Before I do that I want to share one more challenge: Real-Time data. It is near impossible in my experience to get good reporting if you have to manually collate the data and/or the report is purely used for outside stakeholders. To make your reporting effective you should explore ways to make the report automatic based on data that your team already provides rather than making it a separate activity. And to avoid the challenge of stale data, make it part of your stand-up to look at the report; this will help keeping people motivated to update their data. Ideally in any status meetings you have you and your stakeholders look at the tool you use and not extracts, excel sheets or PowerPoint slides; but I have not seen many organisations doing this successfully. 

And now to the promised portfolio view (point 6):
How to keep track of many projects or teams in your organisation? In the manual for Agile it says that you should get your status by attending stand-ups. How do you do that if you have 20 teams working at the same time? I think we all understand that some kind of reporting will be required and as long as it is helpful and used for the right purpose (to provide help where required, not to call teams out where they struggle) we all want that kind of visibility. If you have the relative reporting in place that I mentioned above, you can now use this to get a good view of your teams and you can chart your learning from the past into the report. It could look like this (this is still conceptual as I have not yet implemented it on my program):

portfolio

If you use the relative burn-ups you can now draw each of the teams on portfolio map like the above. Depending on how far they are through their scheduled iterations and how much scope has been accepted you position them on this map. From your experience with successful and challenged teams you know which area is green, amber and red (this will differ from organisation to organisation). But now you can quickly see for which teams it is worthwhile to look at them a bit closer. In the above example the size of the team (size of bubble) and the planned release date (colour) are also shown. As enterprise coach I would talk to the team represented by the large red bubble at 50% of schedule and the small red bubble at 85% of their schedule. At this point you will have to understand the context of these teams to see whether they need help or not. This diagram makes watermelon status (appearing green from the outside but really being red) less likely as it is purely based on the agile burn-up information and your experiences in the organisation. I will let you know how well this works once I have implemented it successfully.

Now this is one aspect of reporting done (status), I will talk about how to report on delivery health in the next post, where we will talk about a delivery health score card and cumulative flow diagrams. As always reach out if you have thoughts or perhaps even good examples.

Agile, DevOps and Design Thinking – How do they relate?

4 Replies

This week I had several discussions in which I had to explain how I see the relationship between Agile, DevOps and Design Thinking. Of course there is no clear differentiation and for that matter definition of these terms (or if there is then certainly not everyone is referring to it in the same way).

Let me start by defining these terms in my context:

Agile (in the context of Agile software delivery)
A set of adaptive methods to deliver software based solutions based on the Agile Manifesto. It is an umbrella term for delivery methods like SCRUM and Kanban and for engineering methods like XP. From a cultural perspective these methods are meant to bring the customer or business stakeholder closer to the IT organisation through closer collaboration and by making delivery less black box and more white box.

DevOps
I personally like the following definition:
“Using governance and automation techniques to optimise collaboration across development and operations to enable faster, more predictable and more frequent deployments to market”.
From a cultural perspective this is bringing down the barriers between the development and operations parts of the organisation to achieve the right balance between stability or reliability and the required changes to deliver to the end-customer.

Design Thinking
This is the process of identifying and defining what a solution should look like by emphasizing with the subjects in question, by creatively solving the problem at hand and by analytically testing whether or not the solution is feasible from a technical perspective and in the problem context (viable for the customer and the business).

Now that we have the definitions out-of-the-way – which I will also use to start my definition page here on the blog – lets look at how all this relates to each other. I will start with a picture that I started to use a while ago:
House of AgileFor me this explains the relationship quite nicely, but not comprehensively. It shows how the three ‘pillars’ that I described above work together to hold up the IT operating model and how it is based in the cloud. Clearly there is more to it than this picture shows and what is missing are the overlaps and differences. This all sounds very esoteric, so lets dig a bit deeper.

So let’s look at the first two pillars: Design Thinking & Agile.
If you pick up the original book by Ken Schwaber it pretty much starts to describe what happens when the Product Owner comes to the team with a list of prioritized items to implement. When I first read the book I had the same reaction that probably many of you had – “If Agile tells me ‘How’ to implement something, how do I find out ‘What’ to implement?”
Design Thinking can be an answer to this question, there are some groups that are really good at this like d.School or Fjord. In my travels it has often been a slightly less elaborate activity like a 1-2 week Discovery phase where IT and business come together to define the solutions, but ideally you use Design Thinking to come up with great solutions. In my MBA I had the pleasure to work an expert in this field and to go through a design thinking workshop and it certainly provided a very different perspective on the problem at hand. In a later post I will describe another aspect of this phase which can be called Design Slicing – the ability to define logical slices that provide value by itself.

Let’s move to the second set of pillars: Agile and DevOps.
Here is becomes more complicated. The previous comparison we could simplify to Design Thinking = What, Agile = How, for Agile and DevOps we wont be able to make such a clear differentiation. Really good Agile adoptions focus on the cultural change required, the methodology changes that come with SCRUM and Kanban among others and focus on the technical practices like the ones that XP describes. DevOps in a similar vein talks about cultural change and technical practices. Here is now where I take a pragmatic approach, for me the methodology aspects are sitting within the Agile space and seeing Post-It notes, burn-up graphs and stand-ups are indications that someone is adopting Agile – whether successful or not requires more than Post-Its by the way. If someone is changing the way software is being coded and deployed and the change is much less visible in the offices (perhaps you can see green and red build lights) then we are talking about DevOps. This differentiation also allows me to break with the conventional wisdom that DevOps and Agile go together. They are definitely better together (like a good meal and a good wine – great individually, even better together), but you can get value from one without the other – just not as much as you could from both of them working together. If I force myself to simplify the difference between the pillars, I would say Agile = Bringing business and IT together supported by methodology, DevOps = Bringing development and operations together supported by technical practices.

I have not spoken about the IT Operating Model and the Cloud.
Let me spend a few words on this as well, by starting with the IT operating model. One of the things I notice when I speak to clients is that no matter how well their Agile and/or DevOps adoptions go that there is a lurking problem that requires addressing as well and that is the IT operating model. Again this is a term that can mean many things to many people. I will highlight a few aspects of what I mean. If you really change the way you deliver software based solutions by using Agile, DevOps and Design Thinking you will likely run into challenges with your existing IT operating model in the following ways:
Funding – Your funding and budgeting process might not allow you to progressively learn and adapt but rather requires locking things down early and measure against that plan.
Workforce management – How can you change from assembling people for projects and disbanding the team at completion to standing teams that work flows towards. And how should these teams look like – teams representing value flows, a central DevOps team or federated accountability, release trains a la SAFe,…
Incentives and Commercial constructs – How do you make sure that all your employees, contractors and delivery partners/systems integrator share your goals and can support the new way of working?
Roles and Responsibilities – How do you need to change role descriptions to make the new way of working stick?
All these are aspects that are not necessarily covered in your Agile methodology or DevOps practices, but that require thinking about and adjusting. And I like to consider this a change of the IT operating model.

And of course we should talk about the cloud – there is lots to say here, but lets leave it with one sentence for now: To achieve the ultimate flexibility and speed to market many aspire to you will have to make effective use of the Cloud (private, public or mix).

Longest post so far, so I will say goodbye for now. Post your comments – I am looking forward to a controversial discussion of the above.