[This blog was inspired by a question in Quora]

V model is a conceptual model between design/requirements/needs and confirmation of those needs in the system. In waterfall, it is interpreted, unfortunately, as a staged model, where each stage is completed before the next step. For example, we want to consider user needs and business requirements as a whole before going into smaller details. On the other side of the V we have the verification/validation steps to confirm that the system meets the identified capabilities. First we go down the left arm of the V, and then climb back up the right arm.

This is a logical model - think of the bigger picture before smaller details, and consider how to confirm the system works accordingly at the different stages. But in the way the waterfall approach uses it, there is a huuuuge assumption behind the staged model - that the identified requirements at each level DO NOT CHANGE during the deeper V stages. A lot of people using waterfall approaches do not seem to understand how critical that assumption is, and how huge the impact is to the successful use of the model.

Automation. If we look at the “economics” of testing, the value of testing is in the number of test cycles that can be run and the speed of how quickly they can be run after a modification. If we can run the tests very often and really fast, essentially after every modification, the cost of creating the tests (and test automation) becomes largely irrelevant.

The reverse is true in “traditional testing”. Because that testing, unfortunately, relies on significant amounts of human labor, it is very expensive to run. Any test comprehensive test run will take countless of hours of human work, and will take significant amounts of calendar time. As a consequence, it makes economic sense to collect a larger set of modifications to test at the same time. Because of time constraints, the actual tests executed will be optimised to most likely areas of failure, resulting in increased risk of regression errors going undetected in areas of lower scrutiny. It also, obviously, means that for many features the testing comes much after the actual development, and therefore decreases the value gained. And, I won’t even go into how bad humans are in repetitive testing. I was a test manager at one point doing exactly this, because I didn’t know anything better.

So, because of high costs of test execution, the focus is on the cost of testing, and that consideration trumps most other concerns. But the focus should instead be in the value seek to deliver through testing, and optimising that (as is the Agile credo in general).

“How does the PM role translate to Scrum?” is one of the more typical questions in my Scrum courses. Here’s the results of one such exercise that we did with the participants to find an answer. 

As can be seen, a large chunk of typical project manager responsibilities become things Product Owners (green in the picture) are supposed to own, and another big chunk is for the Development Team (red). There’s a few splashes of blue (for ScrumMaster) and a sizeable number of items that Scrum is silent on (yellow). 

What is/was project manager anyways?

“Project” is an execution management structure. Projects are set up to deliver some target outcome, usually within specified timeline and budget. 

While I have many stories of release planning, I like to share this one.

Getting started… a little late

I was coaching this game team/organization. The original plan for the next game called for about 6 months of design and development. However, due to other pressures, a lot of things were prioritized over this project and when the first people were able to start the work, only three months were remaining. There was hope that using Agile could help them speed up the development (through prioritization, backlog refinement and faster development), but it was still known that it will be tough.

At the beginning of the work, the game concept was available. A backlog had been built collaboratively with the team. For the first two sprints, only half of the team was available, and they started on the most critical stories. During this time, the backlog was radically refined and prioritized (i.e. features slashed), up to the point that PO started to be concerned that “there was no fun left”.

It is surprising how many IT customers (some of which are actually expected to know a lot about software development) decline to pay for good development practices. Be it preventive QA, TDD, test automation or whatever, many customers assume those are additional costs to them (i.e. by not doing them, they would get their software faster and cheaper – and then they demand up-front planning!).

What if you went to a surgery and only wanted to pay for the room and the surgeon. Afer all, it’s the surgeon who makes the cut and fixes you. How would that go? What else is happening in a surgery theater? There are other medical professionals ensuring that whatever the surgeon needs is available (or is quickly retrieved). Some monitor patient’s vital signs and some control the anesthesia. What about the cleaning staff who take care that the hospital is clean? Sure, it’s entirely possible to make surgeries unnecessarily expensive, but there is certain level which has to be maintained (or else the patient pays the difference). I don’t even know, really, and I haven’t been watching those TV series to be better educated. And I don’t have to; I expect them to know what they are doing.

On the other hand, why do we software developers so often ask customer permission for those things? I don’t ask the staff at a restaurant on how they create my food (and instruct them on not using certain types of knives or grill/oven/whatever they choose to use). I stick strictly to my needs and desires (“and the steak – well done, please”), and trust them to know what they are doing. And if the outcome, or it’s cost-effectiveness compared to other restaurants, isn’t to my liking, I probably choose to use some other restaurant next time.

I sometimes struggle between relative and absolute quality, and how they affect the way we work in businesses and the success we gain. That is, I really would like to think we should strive for better outcomes as a kind of value on its own (and merit from that as business success), but I so much more see “being better than competition” as “sufficient” for most people (and frankly, it is good enough for many companies to stay in business).

In practice, the questions boils down to “we’re already better than our competition, why over-invest?” The way I hear that is “let’s cash in on our advantage now, until we lose it”. I also hear “let’s gain in short term, and figure out long-term competitiveness later”. And I can see the logic in that. But it’s the same logic that has effectively crippled so many companies and destroyed their long term profitability.

I recall reading somewhere that the founder of Ikea, Ingvar Kamprad, once said that “the worst thing that could happen to Ikea would be to go public.” He was referring to the tendency of publicly traded companies to focus on short term outcomes and shareholder value over any other business priorities. While I’m no fan of Ikea, I can appreciate the success they have built (and yea, some few of the items they have designed have appealed also to me). And I can appreciate the mindset.

Systemation writes in their blog about poor project management being the biggest project risk. I agree. Yet I think the blog fails to recognize that the project manager centred and plan driven approach itself is also a major risk for project success. Just like typical waterfall projects (or ones with long increments) omit the most cost effective risk mitigation strategy of incremental development, traditional project management typically omits building collective commitment as a source for getting visibility and low level actions to project risks.

But I won’t belabor the Agile/Traditional divide. What I want to look at is lack of good project leadership as a risk for Agile projects. Given that I agree on the risk, let’s look at corresponding five steps to improve Agile project leadership (note – leadership, not management).

1. All Scrum team members (I’m using the term in the broad sense as that includes the product owner, ScrumMaster and all the development team members) must receive training in the fundamentals. While some of that training can be given in typical training environment (CSM/CSPO classes, etc.), some is most effectively given in a coaching format within the project itself. Too many projects and organization omit the last item, but it actually happens to be the most cost efficient form of training/coaching.
2. The organization and people working in it must agree on some standard framework for project leadership and management. One size doesn’t fit everyone, so the framework must allow appropriate project level modifications. There should be sufficient internal mentoring to ensure appropriate following of the agreed framework and to ensure all project members have sufficient skills to use it effectively. Also there should be a mechanism by which the project organization routinely reflects on the framework and adapts it to changing business environment and needs.
3. All project members should have access to the tools needed to manage the work and use the framework effectively. Note that I didn’t say “software tools”. Many most effective project management tools aren’t software based. But when the organization decides to use a tool, it must support the agreed process (and not the other way around – the organization adapts to the tool).
4. Projects should strive to deliver fully working functionality in every iteration. The ruthless visibility this provides into real progress is the basis for estimation and tracking.
5. The organization must support the projects in their leadership. The teams must be given appropriate time and resources to do their work right and must not be requested to do shortcuts or disregard good practices. Product owners must have support for their long-term planning and vision setting. ScrumMasters need to be supported in their activities for improving project leadership and removing obstacles from getting work done. This is MUCH more involved than most organizations think. It really means understanding what Agile is, what it takes to do it right, and what is needed from the management itself.

Just like the five actions the Systemation CEO believed will improve project management, I believe that the above five actions will improve Agile project leadership. However, action 5 needs significant clarification in Agile context.