I have been thinking a lot about the difference between the PMO activities of old and the way that the Agile process works. Most recently, status reporting…
Someone I met with recently suggested that the Agile way of working is more transparent than the ways of “old”. Their suggestion is there is no room for interpretation of the data, no room for manoeuvre.
I reflected on this and I have to agree. Take a system like #JIRA or #TFS add the Agile way of working and what do you have? Well, if used properly you have more information than any waterfall project could ever give you.
Firstly, lets assume (yes, I am using the word ‘assumption’) that everyone in the team knows how to use TFS (I will reference only TFS going forward as this is the one I have used) properly. Let us also assume that they know the “rules of the road” that have been set out and they follow them.
Let us also assume that an Agile Lead / PM / SCRUM Master / Flow Master ensure that the stand ups / the way the team use the board (knowing how to use something is different to using it!) is all in good order as well.
With these assumptions in place you will create a wealth of data. Here is how and / or why…
As a project starts off you will create the PBIs (or Epic, etc) and slowly these will split out, have acceptance criteria, effort values, business values, etc all assigned. As time passes, the PBIs pass through their lifecycle via whatever Agile methodology you use. During its lifecycle the team will create “interaction” with the PBI. Each time they interact with the PBI they create a data point. Each data point will include the time it was moved, who moved it, what was updated, etc. These data points can also be used for delta calculations – things like how long it was in a particular state, the total time it took to move across the agile board, the length of time it was assigned to someone, etc.
Assuming (yes, it’s that word again) you have access to this wealth of data it would be possible to assess the entire projects health. There is a view producing complete transparency on what activities are going on, who is doing what, how long its taking etc, etc.
Information about single PBIs is useful but not ovey helpful. The gems of information is held in the trends that multiple data points / “interactions” produce. Imagine if you were able to know that a PBI with an effort value of “13” in a functional area of “reporting” was passed quickly through its early requirements phase, quickly through the development phase but really slowed up when it hit “testing”. That would be useful to know as a one off. Now imagine that you see that as a constant trend over three months. You coukd make this information more useful by adding a little more data. For example, you could include the type of report you were working on. This new data would show which reports cause consistent and long delays and which reports were quicker to change.
With the right reporting / dashboard views on top of the data it would enable the senior managers to have a real-time health check on the progress of a project. In theory you could do away with the good and / or bad that comes from a PM creating a status report and the inevitable RAG status associated.
The “glass office” enables anyone to see exactly what is going on and when providing full transparency of the activities being undertaken. The full impact of any change would or could show the impact / effect it has on the project.
The “glass office” is still some time away – well it is for me. Many more people need to adopt and understand the Agile principles and quite frankly TFS relorting isn’t up to it (unless someone can prove me wrong and show me how to get to all that good data out of TFS!)
When it does arrive, I honestly think that it will show its value very quickly.
Yes, it will allow the wheat to be sorted from the chaff in a fairly brutal way, but that’s what we want isn’t it? It will also ensure that high performing teams get the credit that is due – but rather than via an PM spin, it will be done in that brutal, honest and unquestionable way, with core data showing just how good they are…