From Project Manager to Scrum Roles

“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. 

“Project manager” is thus a person who is supposed to manage the project. 

Since projects are about execution, the question of value is often secondary. Or if not secondary, but it’s typically given from the outside and assumed to be known (that is, that the person or board who granted the budget also evaluated the value and found it sufficiently high to warrant the budget). Therefore most of project management is about managing work and cost, because the improvement of value is usually not part of the assignment. Return-on-Investment (ROI) is optimised when the cost is minimized.

Project managers are also hubs of communication. Keeping track of information and status, using that to determine where the project is compared to expectations, and deciding on actions to possibly steer the project (and at least ensure that tasks are being worked on by the right people). Since the traditional project management is about task breakdown, definition and distribution, and then putting them together for releases, this kind of centralized coordination makes sense. Individual project members are experts in their own contribution and do not necessarily even understand all the elements of the big picture. Besides, communication is away from getting their own piece done.

 

What PO gets

Product Owner is a business role. A huge part of the role is the responsibility to understand what value means, and then communicating that to the Team through the Product Backlog, priorities, and milestones. They also get some responsibilities that relate to shorter term, but they often share them with the team.

As can be seen from the picture, the PO inherits all responsibilities regarding longer term progress and project purpose. PO is not a business analyst; the team can usually handle most of that, as long as they have clarity of what is the agreed scope of each selected story. 

“Project”, however, is a poor concept for PO’s in many cases. Even the role name says “product”, and implies that value is an integral part of the role. Unlike projects, products have a variable value element – it is no longer fixed. Increasing value and ROI during the project is one of the essential goals PO’s have when leading development. This is something most PM’s are not experienced in. 

So PO’s may have to be well versed in all kinds of things outside classical project management – sales, marketing, business management, product strategy, product innovation, customer development, etc. In some organisations, the reality of PO’s is quite far from that level of responsibility, so many PO’s can be effective without deep understanding in those areas.

It’s not surprising that many PO’s have titles like “product manager” and “service manager”, although “product owner” is becoming more common.

 

What Team gets

The Development Team is self-organizing, and that means that they adopt all responsibilities regarding the development of the product and the management of that work. This also includes all communication within the technical peers and other teams.

In many ways, the Team role is the most familiar for most organisations, but the challenge of self-organisation is, well, a challenge to most supposedly-self-organizing teams. Most teams struggle taking ownership of their own work management, and often benefit greatly from having a competent ScrumMaster or Agile coach working with them. 

 

What ScrumMaster gets

As seen in the diagram, the SM gets hardly anything. They do receive a supporting role in risk management, escalations and kick-off (according to the picture). Thus, the typical perception that PM’s become SM’s (or “Agile Project Managers”) is a bit unfortunate, since it does lead to quite a few negative behaviors. 

So most of the responsibilities of the ScrumMaster role come from outside the PM role. However, they often do spend significant time helping the PO and the Team learning their roles, so they do at least need to have an understanding of all the responsibilities and activities of those roles. 

All that said, there is one thing that unites the SM and the PM – they both deeply want the project (or product) to succeed. They just take a 180° difference stance on how to reach it. The traditional PM is expected to be right there in the middle and take ownership of taking the team to success. It is their hands that move. ScrumMaster instead sees that they have have find a way to get everyone else’s hands moving, and that in order to achieve that, they have to let go of direct personal responsibility. 

 

And the yellow stuff?

Scrum is silent on pretty much anything outside the immediate control framework, so it’s up to the users of Scrum to determine what they will do with those items. At least in consultancies, there are many things that just need to be done, and someone has to do them in order for the project to exist – contracts, invoicing, customer relationships, steering groups, reporting, etc. I call this set of activities the “project management service”. 

I’ve seen many solutions in organisations. Some teams actually have a project manager who does those things, but they let the PO, Team and SM take care of the content. In some teams, the ScrumMaster does those things, but they need to be careful not to become a PM in their relationship to the Team. Sometimes one of the team members, a senior probably, will take care of that “service”. Sometimes it’s someone outside the team, like an account manager. 

Whichever way it goes, it is important to recognize that a person doing those activities should not be granted formal authority over the team. They should see themselves an enabler and ally for the Scrum Team. They are managers of the things, not the people. And if they are granted organisational power over the Team, they must be very careful when to use it, in order to not break the self-organisation of the Team.

 

So what should a PM do when transitioning to Scrum?

There are lots of different PM’s, and thus it greatly depends on the person themselves.

• Some PM’s already act largely like a ScrumMaster in their PM role, so for them, becoming a ScrumMaster is often a very small step.
• Some PM’s are very business-oriented, so for them, the PO role may come very naturally. 
• Some PM’s are very technical in their background, and they might actually like going back to technical roles and become Team members again.
• Some PM’s seek more managerial roles, and seek to support Agile teams from various organisational positions.
• Some PM’s struggle to find a natural place in the new system and some do check out, looking for more traditional project setups.

Regardless of the chosen role, it is critical that the person understands that their role is no longer to tell the Team what to do. This may be harder than most expect :). 

 

The Essence of Agile Thinking

When you start to use Scrum (or any other Agile framework), it will suck. So you try to fix it. Your mindset will define which way you will go – either back to Waterfall or to actual Agile.

To understand what I mean, please imagine a project that seeks to deliver a customer a system they request for. At the end of the project, we find out that the customer doesn’t like the outcome, despite the fact that it matches their original request. 

 

Why did that happen?

Our brain seeks to understand why things happen around us they way they do. These explanations, for the scenario above, tend to fall into two primary beliefs for the cause:

1. We didn’t do good enough a job in defining the requirements up front, so we naturally built the wrong thing since, well, we built the wrong thing, as planned.
2. We did not show the results early enough for people to detect the difference between “want” and “need”, so we were exposed to actual requirements too late.

The first one we might call “predictable mindset” (or “waterfall mindset”). It is founded on the belief that the most optimal way to build something is to find out all the requirements up front, then plan the optimal way to solve the problem, and finally deliver it according to the plan. In this mindset, when things go wrong, it is because we didn’t do some earlier steps well enough, and the processes are fixed by doing (and spending more time on) the early steps better next time.

The second one we might call “emergent mindset” (or “Agile mindset”). That mindset is founded on a belief that people suck* at defining requirements up front for anything more complicated than a simple physical thing (and there’s a really hilarious video about defining requirements for sandwich) and that the most effective way to detect what people really want is by showing them something and then listening what they say when they try to use it. Obviously, a person with this mindset will think first, to establish what to build as a first iteration, but they never trust the input completely. 

You can “listen” to your own mindset by retrospecting what was your initial reaction or interpretation to the scenario, or when things go wrong in real life. Which response was stronger? Sometimes you trigger both, but probably one tends to dominate in most circumstances.

[* An Agilist would never blame anyone for that, though, since they recognise they themselves are just as bad at defining requirements.]

 

How does this belief affect our use of Agile frameworks?

Let’s imagine another scenario. Let’s say we try to use Scrum for the first time. Unsurprisingly, we will discover many things that do not work fine. The new process feels awkward and in many places it doesn’t live up to our expectations**. Thus, we need to change our ways of working in some way in an effort to try to fix [our use of] Scrum. 

[** Scrum has never promised to fix our problems; only that it will show all our problems to us. It’s up to us to fix our problems.]

If the predictable mindset is strong in us, then the way we fix our problems is by trying to improve the inputs into our process. We will add preliminary steps and effort. We will try to do the up-front planning better, in the hopes of delivering a righter product in a righter way. Multiply this a hundred times, for all the problems that we discovered, and what do we get?

We’re back to waterfall. In our efforts to fix our Scrum, we rebuilt the up-front planning, try-to-do-everything-right-the-first-time process. Every step of the way we tried to improve things, yet we got back to where we tried to get away from. 

If the emergent mindset is stronger, then the way we fix our problems is by introducing intermediate points where we expose our work to our users and customers, and seek their feedback on the things we’ve completed so far. In order to do this, we need to build less at a time, and make it work so that it can be used in some way. It will also force us to discover techniques that allow us to design, code, test, and deploy in smaller steps. Multiply _this_ a hundred times, and what do we get?

The process we end up with may not be Scrum, but it will be very effective at discovering every possible assumption we might have and aggressively testing it on our users. The process will find ways to very rapidly deploy very small pieces of functionality, and also modify anything we have done in the past without excessive costs. 

As a classic Agile quote says, we learn to “turn on a dime, for a dime”, or any other suitably small coin.

And that’s what Agile techniques are all about – enabling us to inflict change on our product without killing ourselves doing it. 

 

It doesn’t really matter which framework you start with

My favourite is Scrum, but I like Kanban almost as much. Lean Startup is awesome, too. I like SAFe less, and LeSS more. But never mind, the selected framework is not really relevant. What is relevant is how you modify it, or how you modify your organisation, as you learn the challenges the selected framework reveals to you. 

The way you interpret causality, and consequently how you try to fix the system, define whether you can be Agile or not***. That mindset defines where the road will take you, regardless of where you started from. It is impossible to make Scrum or Kanban work if your improvements re-establish up-front effort as the standard solution to problems. 

[*** Assuming you want to solve complex problems using Scrum and Agile]

 

So is predictable mindset just wrong?

No. There are many systems, mostly mechanical, where the causality is in fact predictable and where the right approach to fix processes is to increase (or improve the quality of) up-front planning. Most of engineering is in that camp. Also a lot of manufacturing and logistics is there. Waterfall is the archetypal framework to developing those predictable systems. Our very advanced technologies and capabilities are a testament to the value of the mindset, and its application there.

The problem lies in using the same mindset in systems that do not have predictable causality. We need the emergent mindset to explain how to deliver value and improve processes in social systems. And even in engineering, the research and planning of how to be able to do something is a human system and thus “Scrummifiable”, though not in exactly the same way as in software.

So I do not wish to remove the predictable mindset from engineering, only to highlight that a single mindset is not sufficient to understand our reality and be effective in unpredictable systems.

 

Fundaments of Agile

Agile is a mindset. It is more important how you think than what you do, because your thinking drives your actions and behaviors. Repeating motions without understanding is not very useful, and tends to lead to disappointment.

That said, there are also certain behaviors that support the beliefs we have, so ultimately there should be an alignment between the way we think and the way we behave.

There are different ways in which the mindset (and some of the behaviors) have been captured, in the hopes of making the ideas more easy to understand and express. We do, of course, have the Agile manifesto. We also have Lean Software Development with its principles. Two more recent takes are the Modern Agile and Heart of Agile, both of which try to recapture the essence in four main ideas.

All of the above are worth taking a look at, but I will still try my hand to distill the most essential stuff in my own words :). This text is a bit raw, but I’ll post it anyways, in the hopes of receiving some comments to help me onwards.

People

People over Process. That’s our Agilist credo. So no definition of Agile cannot be without attempting to cover the people aspect of our beliefs. And besides, what else is being a human than being with other people?

Delivering organisation

It is important to allow everyone in the organisation take ownership of their own work. This drives motivation and doing the right things the right way. We also need to create an environment where it is safe to be a whole person. We need to build most of the organisation around high-performing teams.

This applies not only to development team members, but also to product owners, managers and internal functions in the organisation. They all need to feel empowered and in control of their jobs.

Customers

Customers are all the people we deliver the value for. Without them, our work has no value. “Customer” covers all recipients of the value we deliver; not just the ones who pay for it. We need to engage them appropriately to give them voice, but they don’t necessarily drive the development decisions.

Process

There are two most essential elements of the process from which all else follows. As far as I know, all proposed Agile frameworks contain these two elements. If we want to cook our own process, we should establish these two and derive the rest of the process on what we learn or need.

Working Software Frequently

Every Agile framework emphasizes the need to have a concrete, working version of the system at frequent intervals. The really working software drives risk exposure and management, proves progress, provides feedback, and delivers value. Without such critical transparency, risks can hide unexposed in the unproven code, progress becomes fuzzy to evaluate, we learn slower and less, and the system cannot be used for anything.

In Scrum terms, we talk about Potentially Shippable Product Increment, but that’s just an example. All Agile processes have their equivalent, regardless of whether the team actually delivers software or something else.

Continuous Learning

To an Agilist, the world is never ready. There are always things to improve. We can learn all the time, all kinds of things. The faster we learn, the faster we become better and faster.

In Scrum terms, Retrospectives are the main component here, but we should not limit our minds to think just them. Any and all learning matters, wherever it happens.

These four key elements interact with each other

Delivering organisation & Working Software Frequently

In this combination, we talk about the value we get, as the delivering organisation, from the frequent working versions of the software. We know where we are, we can control risk effectively, we become fast. Agile here means the ability to inflict change on our product, quickly and effectively.

Look at: CI/CD, Clean Code, Refactoring, Definition of Done

Delivering organisation & Continuous Learning

In this combination, we talk about the growth of people, both in terms of personal growth and skill, and in terms of teamwork. How do we grow as an organisation? What structures do we need to allow our people to be even better? How do we leverage everyones’ best abilities? How do we learn new skills as individuals and organisation?

Look at: Retrospectives, pair working, mob programming, Dojos, Agile HR, Management 3.0

Customers & Working Software Frequently

In this combination, we talk about deployment and the customers’ ability to take the valuable features to use. We talk about speed of delivery, too. We immediately see where we have problems and we can fix them quick. Customers see fast solutions to their pressing concerns.

Look at: DevOps

Customers & Continuous Learning

In this combination, the focus is on getting continuous (and fast and frequent) feedback from our customers and users regarding what problems they want us to solve, how they want us to solve them, and what are the (changing) priorities of their various needs. Our deliveries allow them to refine their desires, and invent new ones. Through all this, we can refine our backlog to more valuable features and, ultimately, hope to see the results also in financial outcomes.

Look at: Lean Startup, Design Thinking

 

All of the above are “true”, regardless of whether the team/organisation uses Scrum, Kanban, or some other framework as their management model. None of the frameworks work without conscious attention all essential aspects. All frameworks have “blanks” that the utilizing organisation must answer for themselves.

Plenty of Action This Year

I haven’t been writing much of late. “Late” meaning “for several years”. Life has taken over – I’ve been busy enough with work, home and family – and I’ve not really been able to take the time to write. I’ve been focusing my work activities on doing great trainings.

And I will not promise to return to more active writing :). But I will try. During the years I’ve learned so many new and great ideas that it would be great to share them in a written format (and not just on my courses).

However, before I get to any of that, I do want to share something I’m very excited about. This year, I’m working with various people to organise a couple of very exciting trainings.

First one in line is my first public Certified ScrumMaster (CSM) course in Finland for ages. I think the previous one was sometime in 2010 or 2011. I’m working with Teemu Hyyryläinen (from Solita) who will be co-training with me. The course is in March 19-20, in Helsinki. You can check out the details here.

But CSM isn’t the most exciting thing – the two other courses are. I mean, I’m rather proud of my CSM courses, but I do them all the time.

The first of the two really exciting ones is the Certified Agile Leadership I (CAL1) course with Olaf Lewitz, Arto Eskelinen and Sami Lilja. CAL1 is a new certification* from Scrum Alliance and focuses, obviously, on the leadership aspect of Agile. So if you struggle with leading Agile teams or wonder what might be good Agile organisation structures, you might find this course interesting.

The CAL1 course will be in May 16-17 in Helsinki. The information and signup is here.

The second really exciting course is a Certified LeSS Practitioner (CLP) course I’m organising with Wolfgang Richter in August 28-30, in Helsinki. Wolfgang has been working with many organisations in Austria and globally to help them organise their larger development groups, and in this course he will share many of the lessons he’s learned. So those of you who want to get multiple teams working together in an Agile way, this is exactly what you need (even if you don’t use LeSS as a scaling framework).

We will create a signup and information page once more of the details are ironed out. If you want to reserve a seat already, please simply send me an email to petri.heiramo@agilecraft.fi.

And last, I was this > < close to organising a Mobile Game Development CSM with Clinton Keith last November. We just couldn’t make the dates match. If you would like to me resurrect this idea and try to make it happen this year, please do let me know, either in comments or by sending me email.

 

Best regards, Petri

* Although, it’s not the certification that’s important; it’s what you learn on the course. The certification is just a recognition that you’ve taken serious effort to educate yourself in an Agile topic.

Organisation Structure in 3D?

The traditional way to show the hierarchy of a traditional organization is with the CEO at the top and the workgroups/teams at the bottom. The Toyota way (as far as I know) is to reverse it, with the CEO at the bottom. I don’t think either shows the diagram as I’d really like, although the reversed model feels much better to me.

The reason is, the CEO role is a dual role of support and showing direction. In the support role, the role is certainly “at the bottom”, providing support for everyone else in their jobs. In the showing direction role, it is at the tip of the organization.

I have often wondered how I could show that duality effectively, both at the same time. Tonight, as I was going to sleep, an image came to me. I had to get up and do it (and then blog it) so that I don’t forget it.

Here’s the image:

It’s pretty rough picture since I had to do it quickly (still gotta get to bed before dawn breaks). But imagine that like a triangular arrowhead pointed towards better future. Read the diagram on the top and the back.

Certainly, that diagram is useful only in the context of more hierarchical organisations. Organizations like Futurice and Spotify are better described with other approaches.

Coaching a Team to Get Started

In those times when I have had more time to work with a team to get them started, I have used the following general outline and found it working. By working I mean, it has struck a good balance between effort invested and value delivered. Investing more time could make things even faster, but not proportionally. Investing less time would reduce value and impact disproportionately. You know.

The Plan for Team’s First Sprints

* Pre-game *

1) Kick-off meeting on first day, to get started (this is more
facilitation than training), including

• What are the things we don’t know? How critical are they to know before we start Sprint 1?
• How do we learn together?

2) High level conversations – concept, requirements, UX, design, architecture, technologies, …

3) Initial release planning workshop

• Vision clarification
• Writing out user stories
• Analyzing the stories for consequences, value, risk, possibly also dependencies
• Building initial release plan

4) Add detail to high priority stories, doing research on unknown stuff (from step 1)

• Coaching for collaborative design

* First Sprint *

5) Sprint planning for Sprint 1, including coaching on good conversations to have

6) Run the first Sprint

• Including a couple of refinement meetings to clarify backlog

7) Review and retrospective for Sprint 1

* Second Sprint *

8) Sprint planning for Sprint 2

9) Run the second Sprint

• Including story estimation workshop and first version of the release burn-up
• Including more refinement meetings

10) Review and retrospective for Sprint 2

* Third Spring and onwards *

11) Sprint planning for next Sprint

12) Run the next Sprint

• Including more refinement meetings

13) Review and retrospective for next Sprint

The Coaching Plan Itself

The coaching plan below assumes:

• There is one team to coach
• More frequent participation is not possible due to e.g. budget or travel
• Two week pre-game, two-week sprints
• Days counted as 5 days per week
• The project has a SM who can carry the duties while coach is away
• The team can learn (or already know) the technical practices on their own

Week 1 – days 1 & 2

Facilitate a 1) Kick-Off Meeting to get people to know each other and aligned on shared goal.

Run 2) High-Level Conversations (possibly at least partly on same day, depending on project size), and help teams have good conversations and get started effectively.

Week 2 – day 6

Facilitate 3) Initial Release Planning Workshop with PO, Team, and key stakeholders. Instruct how to refine stories during the other days of the week ( 4) Add Detail to High-Level Stories ).

Week 3 – day 11

Facilitate 5) Sprint Planning for First Sprint.

Train for 6) Run the First Sprint.

Week 5 – Day 21 (possibly extending to day 22)

Facilitate 7) Review and Retrospective for Sprint 1, 8) Sprint Planning for Sprint 2 and 9) Run the Second Sprint.

Coaching on topics the team feels they like help.

Week 7 – Day 31

Facilitate 10) Review and Retrospective for Sprint 2 and 11) Sprint Planning for Next Sprint.

Ensure the team, SM & PO are ready for a two-sprint stretch on their own ( 12) Run the Next Sprint). Prepare them appropriately.

Week 11 – Day 51

Facilitate 13) Review and Retrospective for Next Sprint and 11) Sprint Planning for Next Sprint.

Discuss with team how they plan to go from here on their own (with remote support, as needed).

Further visits are agreed if the team wishes more support (like every 1-3 months or so).

Conversations with, coaching and training management people has to be considered separately.

Conclusion of the above:

• 7-8 coaching days, 6 visits
• Expectation is that PO, Team and SM can operate as a well-functioning Scrum team independently after the coaching period, with proper practices and a jelled team.
• If there is a lot of legacy, the process probably takes a bit longer.

Possible cost-cutting opportunities (with reduced impact / outcome):

Skip the visit on week 2, and do 3) Initial Release Planning Workshop on the same visit as 1) Kick-Off Meeting & 2) High-Level Conversations.

• Negative impact: the team hasn’t had enough time to familiarize with project information, can be mitigated with up-front study before kick-off.

On week 5, have everything in one day, even if it takes longer.

• Negative impact: people get tired and the planning quality suffers. No real mitigation strategy (coffee doesn’t count 🙂 ).

Longer term goals

Teach someone (like the SM from the first project) to be able to coach new teams (instead of external coach). Then start building a community of SM’s who know the process and can run the process for their teams.

Interested team members start helping other teams in adopting good engineering practices and team behaviors.

Management learns how to support these Agile teams, and barriers for effective operation are removed as they are found.

The Importance of Two Things in Agile

To me, there are two things in Agile from which everything else follows. Before moving on, what are those two things in your opinion?

Getting things DONE

The first thing is the potentially shippable product increment, delivered frequently. In Scrum this means that at least at the end of every Sprint, the technical quality of the product meets the criteria of shipping the product (but it doesn’t have to be shipped, for whatever reason, such as not having a shippable feature state). In Kanban flow, this state is reached at the end of every developed item.

This state means, for example:

• the product has been properly tested and there are no known bugs
• the product has been integrated with its environment
• code is clean and refactored
• documentation is up to date

If we don’t have that state, it should be the most important thing the team works on achieving. It is generally much more important than adding any new capability into the product.

Because, if we don’t have that state, we don’t have 80% of what makes Agile really work. The team is really doing glorified waterfall. “Almost Agile”, but still not Agile. We also don’t know where the project really is, since there is an undefined amount of work remaining in the features created so far (which is exactly the key problem with waterfall based project management). Essentially, we fool ourselves.

For achieving this in software context, Extreme Programming is a necessary framework (or something very very much like it). Scrum and Kanban are silent on this, but it has always been an assumption that smart software teams are aware how critical it is and use it appropriately. For those who have not experienced XP for real, it is unfortunately too easy to dismiss the importance (because they just don’t understand how much it really changes the name of the game).

Relentless improvement

The second thing is retrospectives – the continuous process of evaluating the way of working (including achieving & improving the technical quality of the product).

Unfortunately, this is often the first thing teams omit in a hurry or when getting less excited about their work. This is a symptom of “work harder” belief gone wrong. Yes, there are moments when working hard (i.e. focusing on getting stuff done) is very important, but it should never replace “working smarter”. And dropping retrospection is exactly that.

All examples of really masterful people or teams exhibit retrospection. They spend time to understand the system and focus on finding behaviors that enable them to get more done at their normal effort. They look at the world with new eyes that allow them to rephrase their problem, thus opening opportunities to new innovative solutions.

Masterful teams understand the importance of potentially shippable outcomes, and continually retrospect any faults that escape their process. They want to understand how to further “error-proof” their work. Of course, it’s a work that will never completely finish or achieve perfection, given that things tend to change and some surprises always happen.

And it is not just the process they retrospect, they also look at other elements of their value delivery. How can we better understand our users real problems? Are we able to come up with innovative solutions? Are we creating a successful business? Do we have the right skills or enough variety in our team? Do we appreciate and support each other enough? Are we communicating effectively in our meetings and daily operation? Are we seeing the reality, or an illusion of some kind? Are our challenges big enough to maintain the drive we have?

And everything else follows

If we follow these two elements, we can distill all other practices and frameworks we need.

We probably need to plan what we seek to achieve in some way (e.g. Sprint Planning and release planning). And we also want to replan daily for surprises (e.g. Daily Scrum) and inspect that outcome with stakeholders (e.g. Sprint Review). And so on. We don’t have to choose Scrum as our framework – we can also choose some other metaphor, like Kanban – but the process does emerge from these needs.

We can also refine our general approach. Is an iterative and incremental approach right for all the things we do? Do we need to assign singular responsibility for certain parts (like prioritizing things to do)?

As a consequence, a masterful Agile team will have a great process, but that process may be unlike anyone elses’ process. And that’s the point – they have not copied their process, but evolved it through countless small improvements and experiments. That’s the heart of Agile.

 

UI Design in Scrum

Again, I’ll post an email response to question from an alumni.

The question:

I am working on an agile project and I don’t know when to incorporate prototyping.

The project is a private web application with a number of complex workflows. We have developed high level user stories, but we would like to validate some of the user stories by testing them with a clickable prototype. 

I can approach this a few ways, and I am a little confused. Maybe your advice could help me.

Option 1:  I treat the prototype as part of the user story, as part of the iterative process. I build it into the sprint process and validate it during one of my sprints and iterate from there. 

Option 2: I conduct the prototype work separately before I incorporate it into a sprint and make it part of the discovery / validation process at the beginning of the project. This is how we handled the prototyping for the example I shared. The design/ux team developed and validated the prototype prior to putting the user story into the sprint.

Option 3: A better solution from Petri? 🙂

To me, both approaches mentioned are valid approaches (what is an invalid approach? One that never works? Anyway…).

 

I would use option 1 in these two scenarios:

• The amount of uncertainty is manageable by the team without undue disturbance to other agreed items.
• All, or most, of team’s work is stories like this. Thus, it is just the natural form of stories for the type or stage of the process, probably an early explorative stage of the product development.
• There is great haste to moving the item forward, and it is better to commit to uncertain work (and face the consequences) than to spend time learning first.

 

I would use option 2 when either:

• There is significant uncertainty about the thing to be done, and the team would not feel comfortable committing to the work as a Sprint story.
• There are some constraints, like an approval from third party, and that stakeholder is not reliably available for normal sprint work. For example, the appearance has to be approved by Marketing.

Many product programs end up using “two teams” – the development team and the research “team” – that share some of the members. Imagine this as two overlapping circles (which are inside a larger circle – the product). One is focused on developing well-understood stories into Sprint releases, the other is trying to understand what is worth doing. in Scrum terms, the former would be the Development Team, and the latter would be like a Product Owner office (consisting of the PO, some external stakeholders, and some of the team members on a part-time basis).

Both “teams” would have their own flows. The Development Team probably uses something like Scrum, with agreed batches (but they could also use Kanban-like flow), given that the work this team undertakes is probably well understood. The research team is likely to use a Kanban-like flow, given that the work is highly uncertain and there probably are more “balls in the air” at any given time (i.e. there is research work going on in many epics/stories at a given time, and it is not necessarily very clear how long each item will take).

Most Development Team members spend 5-10% of their time in the research team, but some members, like UX designers or domain experts, may spend as much as 50% of their time there. This depends on a given Sprint and will fluctuate as needed. The people must manage their participation in both flows in a responsible way :).

A blog post looking at this model in more detail can be found e.g. from Marko Taipale.

 

And there is a option 3. It’s not better, just a slightly different approach.

This approach is called “spikes”, “research stories”, or a few other names. It’s kinda like a combination of the two above. Take a research item, write it as a story, and put it into a Sprint. The outcome is a learning outcome, not a product increment. The trick is, these items are not estimated, but timeboxed. In the Sprint Planning, the Team and the PO agree how much time is spent on that item, max (i.e. less time can be spent if a solution is found in that time). When the timebox expires, the team ceases working on that item and reports whatever they learnt in that time in the Sprint Review.

I would use this approach when:

• The research items are reasonably few in number (like 0-2 per Sprint)
• There is no “PO office” to handle research
  • Or if there is, but the item is heavily related to the “How”, i.e. technical domain)
• The PO or the Team want to learn first (in a low-cost way) either about the What or the How, before being able to refine the story further and commit to actual development work.
• The work can be time-boxed and easily fits inside a Sprint (i.e. there is more development work than spikes in a Sprint).

Getting Agile puts useful additional detail on this option. Also Agile Atlas has a section on this topic.

Depending on circumstances, I might use all three approaches in a project, as appropriate. Each has benefits that some stories would benefit from.

Hull Speed for Systems

I have noticed that all systems have some natural capability for
productivity, value delivery and quality. As the people in the system
gain experience in the system, their performance will start reaching
that systemic speed. Just like with a ship, this happens quite easily,
but when the “hull speed”* is reached, the amount of effort / power to
go faster dramatically increases, up to the point that a certain speed
seems unsurmountable regardless of power expended. In systems, we can
perceive this e.g. in overtime, which does not yield real benefit
since the extra effort translates to more mistakes and other negative
factors that detract from real progress.

I continually observe that also in the ball point game, where people
psyche themselves to try harder, but they still get the same result.

Also, waterfall has a certain hull speed. No amount of pressure will
make it deliver stuff faster.

Organisations, as they are composed, also have a hull speed.

The only way to go faster than the hull speed is to change the system
into one that has a higher hull speed. E.g. starting to use Scrum. But
any given set of practices also has a hull speed. And the only way to
go faster (after the learning period) is to change the practices to
ones with higher hull speed.

Thus, we can say that any action that does not affect the system’s
structure and fundamental behavior in some way (and merely is an act
to “shape up”, “increase discipline”, or “try harder”) is very
unlikely to produce any lasting effort. Any benefits gained from such
activities either produce negative side effects that ultimately cancel
any positives, or disappear over time as the system returns to its
hull speed.

TL;DR: Work smarter, not harder.

 

* I know that hull speed is technically a little different from that,
but a layman’s approach is good enough for this concept :).

Story of Release Planning

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”.

The Wall

At the beginning of the third Sprint, the rest of the team joined in, and on the third day of the sprint a release planning meeting was held. At this point, the team estimated the size of the items they had already completed (in story points) and used them as a scale for remaining items in the backlog. Based on the stories completed, the estimated total capacity of the team (for the rest of the planned sprints until release) was about 350 points (give and take a bunch). The size of the remaining backlog was estimated at 1300 points.

The lead dev’s estimate of their chances of success went from “optimistic 20%” to “definite 0%”. The sprint was terminated. Everybody scrambled to figure out a new approach with even a slight hope of success. The CEO could not find a feasible solution by extending the release date or otherwise renegotiating the contracts with the publisher. The team looked at their work and tried to figure out simpler ways of reaching the goal.

The New Plan

Luckily, the team’s previous game had a lot of similar elements as this new one (which was kinda considered “2.0” in many respects). However, it was considered severely lacking in technical quality (though it did work). Thus the team had planned to rewrite the core architecture to allow for future extensibility. Upon closer reflection, the team felt that it was possible to return to the previous game and simply modify and extend it to enable the new game design. A new plan was created that would allow them a shot at successful delivery, assuming that they could meet the weekly goals successfully.

Prior to this planning event, the idea had been to practice and implement Scrum in this project. It was decided that there was simply no time to practice, but they decided to continue with the team level elements that they had learned already. Also the new plan did resemble a Scrum flow with its weekly goals and they did review the plan weekly. They also tested a lot each week to ensure it was working sufficiently well. They also ran a beta test alongside the development during the last month.

During the remaining two months and a bit, they actually were able to create a version of the game they were able to ship to publisher and game reviewers. And they also took Steam to use, allowing them to refine/polish the game post-gold since the platform allowed for a forced update upon installation. While it wasn’t the game originally envisioned, it was good enough. And, the team actually did without a similar crunch as they previous releases (but it was still tough 2 months, just much less pressure in the last month and some). So they attributed a lot of the success and reduced stress to the Scrum coaching.

Aftermath

Irony of the story? After the release of the game they decided that they didn’t want to make games like that anymore. So any refactoring of the architecture for future would’ve been a wasted effort. Realizing that they were running into a wall ended up saving huge amounts of effort for them (against an essentially fixed payout for game delivery).

And they did continue using Agile ideas in their future games. They’ve been happy with the increased team collaboration and have continued with the new culture. And the lessons about user stories game them a very good foundation to create increasingly growing game versions instead of “everything at the end”.

If that planning had been any later, it would’ve been a disaster. Any earlier and we might’ve not been able to see it as well. And without the coaching it would’ve been a huge mess for everyone. While this is speculation on my part, the coaching maybe saved the company.