Working From Agile First Principles - ShaneDrumm.com

Working From Agile First Principles

When I joined the rogue team of Whisper they had their own version of Scrum. No estimation, refinement, reviews, retrospectives or planning sessions but they did daily stand-ups and used jira scrum board nearly every second week; most of the time.

This said they were still functioning and were probably a small bit too Agile at the time. Now they do all the Scrum cermonies and even have a Kanban board for support and operational work. We have had people go on holidays, out sick, huge support distractions andwe still have been able to move forward.

It might be easy to say now all you had to do was introduce all of these cermonies and process and it will happen organically but if I did it would of been too much at once and all rejected.

If we revert back to the 12 Agile Principles they were actually meeting most of the 12 with a few exceptions so was it really that bad to start with?

  1. This is the one thing the team were excellent at. Being a rogue splinter for the main company they didn’t adhere to the rigourous release process so were free to release when they wanted. Image result for check
  2. The requirements were being developed in a rolling wave approach so change was always expected Image result for check
  3. Before I had started they had missed some crucial deadlines which didn’t start us off on the wrong foot so we did have hard date to meet and we made a mini-project plan to meet it. They had delivered working software but they needed to get certification by a certain date which required meeting a strict testing procedure Related image
  4. The business person was the prodct manager who also was the business anlayst and the system architect as well as few other things. Critically he sat with his team so really had our own war area for Whisper Image result for check
  5. This was Whisper a safe and trusted environment protected by the product manager  Image result for check
  6. A daily stand up and using jira is not agile processes no matter what they tell you Related image
  7. Exactly what the team focused on Image result for check
  8. The team sat together and spoke every morning as an update including a business update but there was continuous interaction throughout the day Image result for check
  9. The approach we took was a bit different due to time constraints and most definately not most optimal but ot worked for a team who had to hit deadlines and deliver Related image
    • Make it Work
    • Make it Right
    • Make it Fast
  10. We were very good at this Image result for check
  11. The team had no choice but to be self-organizing Image result for check
  12. Nope and retros were the first things I introduced Related image

8/12 is not too shabby especially after reading that it was a sticky tapped version of scrum. There was a really good base to work from for these critical reasons:

  • The team had a clear vision on what to deliver and by when
  • The team worked together closely and constantly interacted with the product manager/business analyst/architect
  • The team was in general protected from the business and it was all absorbed by the product manager
  • The team wasn’t held back by processes enforced in the company from scrum to releasing.

That said the business was not very happy with the Product Manager or the project as they couldn’t provide any plan or achieve any of the previously agreed milestones. For this reason, the head of engineering hired a project manager a week before I joined and one of his first meetings he was given an ear full about how behind schedule he was and how is he going to fix it.

So when I joined I had plenty to do, probably not what a typical product owner might be expected to do so lucky enough I’m not a typical product owner.

>