Archive for March, 2015

Scrum in a BAU environment?

Monday, March 16, 2015
posted by daveb

Allow me to share a question, and my response to it on Linked-In’s Agile Coaching group.

Q:

Do you have any ideas or suggestions on how to improve the team focus while the Scrum (Ops) team works on several changes that sometimes don’t have a relationship?

Context: A mainframe environment of >6500 COBOL programmes where several highly complex regulations are gathered in one system.

A:

We have a very similar problem – one Product Backlog, one Scrum Team but the work that some team members do has little to no impact on what other team members do, to the point where they have independent test/release cycles. There’s probably 3-4 separate sub-teams, sometimes with overlapping resources, working on separate products that occasionally interact.

In Scrum terms, Scrum of Scrums is the advice on how to scale Scrum. This may be of benefit to you if you have say > 20 people involved, but for us with 9, it seems like too much ceremony.

I think there is perhaps an absence of good advice from Scrum around how to run Scrum with a small team & a diverse range of products. Scrum can still work, but there’s more waste in the form of exposure to communications that have no bearing on your work.

I would question whether Scrum is the right fit. Scrum has a sweet spot that is around complex (single) product development efforts with team(s) of 3-9 members, where much of the work is in-sourced, and the team is co-located.

It may also be worth looking at Kanban which has its sweet spot in product maintenance and support, because, chances are, if you have a small team and a diverse product portfolio to manage, you are in BAU mode.

Doing everything at once

Monday, March 2, 2015
posted by daveb

What happens when Requirements Analysis, Design, Development and Testing all happen at once, on the same features?

Common sense software project management says that  Requirements Analysis, Design, Development and Testing are distinct Software Development Life Cycle (SDLC) phases that happen one at a time, each being dependent on the step before it. This is what we commonly refer to nowadays as Waterfall (before Agile I believe we simply called this Project Management).

Agile & Lean based methodologies point out that we can view a software product as a group of features, order them according to business value, then start work on Requirements Analysis for the most high value items first. We then pass those over to Design & Development while we are do Requirements Analysis for the next most high value feature, and so on, creating a pipeline with different features at different stages of delivery (a value stream).

But that’s not exactly what I’m talking about here – I’m talking about doing Requirements, Design, Development and Testing for a single feature at the same time.

Common sense also says that doing all of these things at once is not only a bad idea, but simply not possible. For instance, how can Testers test software that has not been Developed yet? (This is a common assumption that is incorrect, because testers have a lot of value to add to a team than simply testing).

Therefore, I was surprised to find that on a project I am currently working on the team had self-organised to do all four activities at the same time, for the same feature. And you know what? It was the most productive we have been in months!

So how did this work? Admittedly, Requirements Analysis had a head start on the other activities. Design commenced with the Requirements in an incomplete state – they were more or less correct, and covered most of the ground necessary to describe the the business need, but completely lacked the depth of analysis necessary for the Design, Development & Testing activities. The Designer had no choice but to start by clarifying the Requirements i.e. the Designer was asking a lot of pointy questions of the business to make sure they had thought through what they appeared to be asking for, and looking to flesh out some shallow requirements with greater depth.

Meanwhile, the Developers had been able to make a start on the infrastructure parts of the solution, and they were able to start building and refining the solution as new information and clarity came from the Designer’s work. The Design & Development team, and in fact all team members worked very closely together. Most communication was verbal.

At the same time the Tester was able to start working with the Designer and the Business Analyst in charge of the Requirements to start gaining an understanding of how the system was supposed to work, and what he would need in order to test it. He was able to start doing productive work well before the Development Team were anywhere near completion, and was able to question the Requirements and add clarity there.

The result: so far this appears to be working extremely well, although I won’t declare it a success until the project is delivered. The key improvement over the staggered waterfall approach is the quality and intensity of communication within the team. Everyone is talking about the requirements, the design, and how to test it, all the time. It’s a real buzz to work in an environment of rapid-fire discussion, thought and communication and it helps bring out the best everyone has to offer. This is how a team would work if it had an impossibly short time frame to deliver, and their lives depended on getting it done!

The irony of this is that we are supposed to be working in a Waterfall project management environment – but that was working so badly that the team members basically self-organised and did whatever gave us the best chance of success with a deadline rapidly approaching, and all eyes on our team.

In order to make this “Do everything at once” approach work, you need the following:

  • Co-located, small (3-9 member), cross-functional team.
  • Safe communication environment – anyone can say what they need to when they need to. There is respect for all opinions, no danger of a boss overhearing and suggesting we are not doing things the “right way”.
  • Professional, transparent, capable team members in every discipline.
  • You need a coordinator role on the team. I suggest the Designer fulfills this role since they are in the best position to bridge all the disciplines. This role needs to communicate the constant stream of changes to all the team members.
  • No formal change control processes around the Requirements & Design activities.
  • No blame. Instead of blaming the business for its poor requirements or the lack of design documentation, dive in and make them better.

Would I recommend this approach? No, not as general advice, but in the right circumstances, it is definitely worth a try. At the very least it’s worth a try if you are falling behind schedule, everyone is blaming everyone else, no one is talking etc. – what have you got to lose?