If you were to have asked me about five years ago about agile team and organizational assessments, you might have gotten your head bit off. You see I used to be violently opposed to formally assessing agile teams in any way.
The roots of it probably related to aggregating team velocity. If you’re wondering, that’s not such a good thing to do either. I was worried about teams comparing themselves to each other and creating unhealthy or dysfunctional behaviors. I also worried about what THEY (leadership, managers, Project Managers, HR folks, etc.) would do with the information.
Now I’ve always felt that having maturity data around, in some form, was helpful to seasoned agile coaches. It just gets hairy when you start using it for organizational and x-team metrics. And it’s the inherent “metrics dysfunction” that is always lurking in the shadows this is a real concern.
I honestly believe that having high-energy and high-impact Sprint Reviews truly differentiates high-performance agile teams and organizations. It's very much of a "Show Me the Money" moment for the team. It allows the team to be transparent and demonstrate their results. It allows the organization to provide feedback. And it serves as a progress baseline / milestone so as to measure progress towards established goals. And finally, it should be cause for "celebration".
In many ways, agile delivery is about Earned Value, and EV is demonstrated one sprint at a time.
Does anybody remember the Cool and the Gang song Celebrate?
I sure hope so.
I want to write a short post about celebrations. For some reason I've encountered quite a few teams lately who are struggling. They're completing sprints and releases without getting much in the way done or meeting expectations.
In other words, they're ending their efforts: sad, depressed, without a sense of accomplishment. In a word, they’ve got no reason to – Celebrate.
Of course there are many reasons for it and I can't possibly explore all of them here. But the examples have made me reflect back on some of my best experiences with teams delivering “the goods”, and I wanted to share an example.
By definition, agile development is a team sport. The emphasis is on teams working and delivering together. It’s not measured by how many user stories the development team produces, but by how many completed/done stories the team can produce.
Quality is not something “owned” by the testers, but the responsibility of the entire team. In fact, you don’t try to “test in” quality, but rather “build it in”.
It places collaboration and teamwork above individuals working alone. It values pairing and swarming around work. It values limiting WIP so that team members work together.
Several years ago I went to an agile conference, actually the annual agile conference put on by the Agile Alliance. One of the sessions was a 90-minute workshop put on by an incredibly experienced agile practitioner. In fact he was one of the original 17 signatories of the Agile Manifesto.
I got to his session early and I’m glad I did. The room became packed, with every seat take about 15 minutes before the session was scheduled to start. Then the floor started to fill up. By the time he arrived, the room was over capacity and the anticipation was electric.
I’m often quite wordy in my blogs. I’ll pose an initial question in the title, throw out a thousand words or so, and then present a conclusion. I’m not going to do that here. Instead I’ll be much more succinct.
Is forecasting evil in agile portfolios?
YES!
The context for this conclusion and subsequent discussion is three-fold:
- Forecasting when you are just building your agile teams OR are in the early stages of an agile transformation;
- And, when you’ve been doing agile for awhile, and you’ve become overconfident with your capacity awareness;
- And forecasting in this sense is anyone determining how large or how long something will take and NOT fully engaging their team in the estimation, planning and forecasting.
Derek Heuther, in a blog post on the LeadingAgile blog, took the position of replacing traditional Backlog Grooming with something else. The blog post can be read here.
There are two “parts” to Derek’s post.
First he provides a brief history of the practice of “grooming” and a sample of references – including a Scrum Guide reference.
Then he explores what he calls a Progression Workshop. Here’s the core of what he says about the workshop:
This has been an ongoing debate for a number of years. There are essentially three groups of Project Managers:
- Traditional Project Managers – they’ve typically operated in Waterfall environments and frequently reference the PMBOK. They often follow best practices, templates, and models for effectively “managing” projects. Usually they view success to be plan-driven.
- Agile Project Managers – who are normally quite different than their traditional counterparts. They focus on the team and are more facilitators and coaches than project managers. They also consider success to be team-driven.
- Then there are Traditional Project Managers who want to play in agile environments, so they start looking for specific tools and techniques that they can “borrow” from the agile approaches. They take more of a hybrid approach to project management, and this group seems to be increasing as agile approaches have become mainstream. Often these folks have acquired PMI-ACP certification, but they have little else in the way of real world agile experience.
I saw the following question in the Agile and Lean Software Development group on LinkedIn:
As an Agilist, what kind of constraints do you use to ensure quality?
There were quite a few thoughtful comments, for example:
- Definition of and adherence to a – Definition-of-Done
- Collaboration and pairing
- Unit, integration, and regression testing
- Sustainable pace
- Measuring defect and process “escapes”
- Appropriate testing as EARLY as possible
Not that long ago, I received an email from someone in the Northwestern part of the US. They were thinking of moving to agile approaches and they wanted to pick my brain surrounding the logistics of “going Agile”. It was an introduction of sorts, but it was also an assessment.
They were assessing whether I knew what I was talking about and whether they’d allow me to help them. They were also assessing cultural fit. But I was also assessing. Were they “ready” to try agile, were they serious about it, were they self-aware, and would I like to work with them.
It was a great meeting and it led to some interesting follow-up activity. But I remember a conversation distinctly to this day that I wanted to share with you.
