Over the past few years I’ve had the opportunity to work on many teams that call themselves agile. While teams can do the agile process, they may not have an agile mindset.
I’ve always held out that agile was a state of mind moreso than a process. More allowing porous flexibility, than stories and iteration planning. As PM transitioning from iterative to agile, it’s been a bit bumpy for me. I’ve wanted too much process, or perfection in documentation – or even too much standardization. Allowing for being agile can feel chaotic (though as an aside, allowing for a bit of chaos is probably where Project Management should be heading ).
I think it helps to re-read the original agile manifesto. It doesn’t talk about user stories, or iterations or task estimation. It talks about a mind set – a mental approach, and a set of values.
I thought I’d share my learning with you. So as a PM, you can have some practical indicators of where your team is with this whole agile mindset thing.
Here are some things a good agile team does:
1. Finds the root cause
AGILE: When a problem presents itself, a truly agile team swarms around the solution. They figure out the problem and then prioritize it. Because they believe that software should be consistently workable, they almost take it personally when it’s not. So they really want to know why something is not working and they spend time to figure it out.
NON AGILE: Non agile teams tend to initiate surface fixes and then save the root cause analysis for a later time. They are not as passionate about finding the root cause.
2. Questions process and documentation
AGILE: Transition to true agile from iterative was a bit of a challenge for me as a PM. I had to get used to people making me justify why something should be documented. Truly agile teams know the difference between documentation that will sit on a shelf and documentation that will help build great software. And they police themselves, and their leadership, to make sure they don’t waste time.
NON AGILE: Builds in on the shelf documentation into the process because they believe they have to do the work. In other words, they don’t really question authority in this regard.
3. Doesn’t update jira/rally/asssembla that well
AGILE: Another pain point for me, which I have accepted will always be a pain point as a scrum master, is that status updates to story tracking systems is going to be light. I cannot tell you how many times I’ve commiserated with other scrum masters on this point. Better to just accept it and send out the weekly/status – please update your stories/points email.
NON AGILE: Focuses a lot of time on status reporting. Tends to fill out all the fields in the story tracking system. Tends to also then assume that an status email/report must also be filled out.
4. Wants product owner approval
AGILE: Agile teams hesitate if you suggest that you just push code without PO approval. A good agile team trusts, respects and wants the approval of the PO – because that enables them to produce a good product. This is part of the process they actually want to stick to. Even if a release is held up, the agile team will wait for PO approval; schedule be damned.
NON AGILE: Non agile teams tend to push code according to a schedule. The PO had better get on that schedule or they will miss the demo opportunity. In other words, schedule trumps PO approval.
As thoughtworks empahsizes so well, its the differnce between Doing Agile and Being Agile
5. Handles changes without a lot of theatrics
AGILE: Change is welcome. There’s a positive inclination to take a minute and be open, respecting the change as legitimate. This team believes that change is ok – so they have a process built already for efficient processing of changes, and they throw the change into that process.
NON AGILE: Non Agile teams have a process that slows the review of the changes. It’s not an immediate understanding, review and prioritization. Instead you’ll see a change go immediately to backlog. The backlog then grows and grows until no one understands or remembers why something was put there. Then the theatrics begin with the client, who is wondering -> what happened to that thing I asked for – I’m still seeing this bug?
6. Gravitates towards bite sized chunks
AGILE: Agile teams don’t accept large chunks of work. They will scrum around something big and break it down into small chunks.
NON AGILE: Breaking down a task means a) that you can hide within it and b) other people can’t pick it up. So non agile teams accepts a large chunk of work and won’t try to break it down.
7. Consistently tries to figure out how to make things more efficient
AGILE: Agile teams ask the question; how can we be more efficient, faster, more productive. They tend to revisit infrastructure, metrics on systems and incorporate automation into the process (like build servers and CI).
NON AGILE: Tends to revisit infrastructure, efficiency, metrics questions when things stop working or slow down to a crawl.
An Agile mindset is just that – a state of mind, a set of values. Its a constant questioning, and an opening up to possibilities. Its a predisposition to produce great things.
Take some more time with this presentation from Thoughtworks.