Do more Less - in fact do much more Less

In my last assignment I found myself in a company in denial. After two years on their agile journey they thought they were making progress, they weren't.

Despite being given some basis agile/scrum training (the classic 2 day course) two years prior, there had been no-one to mentor in the behaviours and best practice that actually make Agile work. TFS has been implemented and deemed to be "Agile" so therefore job done eh!?

This meant that Agile was not actually in existence. The Business were not engaged, stories were not being written well (actually most were awful), there was no pairing or Agile best practice in development and there was a massive silo culture of Development and then Test. This "wall" between them meant that each item being delivered simply followed a waterfall design/build/test process within an arbitrary wrapper called a "Sprint".

The really sad thing was that no-one was happy. Developers were stuck in big tasks (20-plus point stories being played) and over-engineering what needed to be done. Testers were building out test plans to give as much coverage and risk reduction as they could to the work and would only see the app after Dev had finished it and moved it to another environment for testing. Also the Business was not releasing anything at all and had basically seized up.

One thing that immediately struck me was that apart from the complete breakdown of scrum, there was way too much being done. Lean principals in software development and testing had not emerged anywhere and there was a BDUF mentality. Developers were waiting on Architects to "design" what they needed to implement and Testers were waiting on Developers to build this design. This lead to over-architecture, too much development (lets fix/replace this at the same time) and then Testers were building massive test catalogues to attempt to give coverage across everything that was being built or refactored.

What did this mean?
Q: "How long to change this single report template?"
A:"A week to build and two weeks to test"

I heard testing estimates of up to three months being given for what were very straightforward changes, often driven by the fear factor (unfounded!) that the whole platform would break if someone waved a keyboard near it so the whole thing would need manual regression testing.

I needed to fix this and I coined the phrase "Do more Less.." (e.g. Do more Less Testing) and set about unpicking the pervading culture and concerns that it was all too difficult, and that everything would go wrong if absolutely everything wasn't risk tested surrounding every user story.

I got the product owner re-engaged, got the user stories back to a small "proper" size and format, then encouraged the testers to create small simple tests that only covered the contents of each user story (this immediately sowed the seeds for some TDD too). Once we were in this position I then encouraged (well, bullied) the testers to work with the developers and begin testing in the Dev environments as soon as the code was being crafted, rather than waiting to see it on another environment once finished.

Guess what, everything started to speed up. Testers were spotting errors within minutes of them being coded or spotting ambiguities in the requirements which analysts could iron out; Developers were focusing much more on the smaller stories and not getting bogged down in wide-ranging architectural change; the product owner suddenly had tangible things to see at show and tells (which had fallen by the wayside a long time prior) and "Agile" practices began to emerge.

Coming back to the point of the post though; in getting the teams to work on much smaller things, and do the minimum needed to deliver them and assure their quality (rather than worry about everything around it), they were doing less work per story ...a lot less. This in turn enabled everyone to do a lot more of Less work which in turn meant productivity went up, the team literally was delivering three times faster and everyone was suddenly a lot more cheerful about Agile!

Do more Less  ..much more of Less. :-)

Tools don't make you Agile

So this is my mug from a recent assignment. We were all issued one within the Capability Team but it was supposed to remind us all that when we'd finished all our stand-ups, facilitation workshops and face to face interactions, that at the end of the day we needed to update our supporting toolset.



Keep calm and update Rally

The challenge with adopting Agile is that you need to learn new agile values, and its not easy. Giving developers or technologists the choice of interacting with business people or playing about with a new toolset there is often a sway towards tools and insular practices.

In Agile, its all about the people interactions and conversations that make you more Agile, and you can get the most of them happening when you have an agile wall / 'radiator board'.  These walls tell their own story about the status of any project and will attract any interested parties like moths to a light bulb. If this board is in a collaborative space it will encourage the business and technology to openly engage with it and with each other.  The six conversations* you're going to have about each user story are easily enacted in this space with physical media (cards and pens) rather than a screen.

If you use desktop tools you promote people to look at their own screens rather than each other. I call desktop tools 'fridge's' as you've got to open them to see what's inside, unlike your Agile wall that is always radiating information. The human brain can happily manage about 150 items in view and in context on a wall, so only got for a supporting toolset if you're way over this amount, or you have specific geographical challenges you can't overcome with other means.

Any organisation that thinks rolling out Rally, Jira or whatever to their tech department is suddenly going to turn them Agile is starting off in the wrong direction.  Toolsets can help make your processes more efficient, but they don't make you "Agile".

*A user story is a placeholder for a conversation, one that will take place about six different times before the story gets played into a scrum team.

On the journey

So every journey begins with a single step..

Today I was running a session to elicit a list of potential projects with the business so that they could be further analysed by process and technology and then played back to the business again for a short-listing.

Its good to be back in the facilitator role again

Whilst we got the list of projects together in a reasonable time and some excellent debate was had, it was interesting to observe the worry in the room that there was not going to be a concensus on priority.  The concern seemed to be that either some "quick wins" that would be easy to deliver would make it in, or alternatively just a start on a more strategic journey that would deliver big benefit down the track, but not necessarily in the coming year.

Thankfully, I was able to speak to the concern using Weighted Shortest Job First (WSJF) and had printed out a copy of the formula and a description of the elements that make it up.  There seemed to be a real sense of calm coming back once I had explained the inputs and process and that there was an existing method to take stakeholders on a journey to a potential "straw man" priority list that they could then debate with some actaul "science" behind it.

I just hope they like the answer when I run the prioritisation workshop in a few weeks, I have yet to crack exactly how we are going to get an overall clear measure of "business benefit" here.

More to come..