This exercise introduces and demonstrates the “Means First, Then States Syndrome” and the negative impact it could have on software projects’ execution and/or outcomes. It also drives a meaningful discussion on what success is to software projects and what factors could lead to it (including an evaluation of the values and principles of the agile manifesto). It further emphasizes the importance of stakeholder theory and stakeholder analysis.
100 mins (but depends on the number of teams / discussions held). Each part of the exercise is strictly timeboxed.
Papers, pens and timer for timeboxing.
Introduction (5 mins)
Split people into teams of 3 to 5 people. Distribute papers and pens to the teams and explain the rules of the exercise described below (5 mins)
ROUND I (30 mins)
Part I (20 mins)
Give teams 20 minutes to come up with a list of factors that lead to successful software projects. Success factors could be anything related to people, processes and products (if you’d like to use the 3P / holistic view of organizations. Examples for such factors in terms of people might be individual characteristics as competency, accountability, creativity, discipline, etc. or group / team characteristics as cooperation, respect, engagement, authority, etc. They could be way too narrowed as are cross-functional teams, self-organizing teams or any other well-known “best practice” in this regard. Some examples for success factors related to processes might be effective communication, resources utilization, performance, flexibility, etc. More concrete examples could be process formalization and specific software development life-cycles, specific organizational policies and work procedures, working environment, etc. On the product side success factors might be quality, innovation, simplicity, etc.
Part II (10 mins)
Teams now have a list of factors that lead to successful software projects. Ask if any of the teams have defined what a successful software project is? None, I would suppose. This is what I call the “Means First, Then States Syndrome” (or even “No States Syndrome”), where software engineers tend to focus on the means or how-tos before they actually know and completely (and mutually) understand what the desired end states are (or just making assumptions based on their previous experience, peers’ behavior, etc.). It’s also related to the tendency some people have to “Act First, Then Think”.
Ask teams to explain how they feel. I’ve called the “AHA” moment when you understand that you’re trying to be successful without knowing what successful really means as feeling “successfool”. How often do the teams feel “successfool” in their real software projects?
If there’s a team in Round I which had defined their understanding of successful software project (before listing their success factors), the team wins 10 points.
ROUND II (30 mins)
Part I (10 mins)
Ask each team to come up with a definition of a successful software project (Definition of Success in analogy with Scrum Definitions of Done, Ready, etc.). It could be free text, a list of criteria (e.g. business value, customer satisfaction, organizational performance, team motivation, etc.), the well-known project management triangle (scope, time and cost) or anything else. This could be also used to introduce the importance of shared understanding in the agile world (e.g. the practices in XP for shared understanding, the sprint goal / definitions in Scrum, visibility and transparency in Kanban, etc.).
Part II (20 mins)
Now ask teams if their Definition of Success represents the interests of all possible organizational / project stakeholders (all those who might affect or might be affected by organizational / project’s execution and/or outcomes)? Does the definition represent the interests of the customers? What about the shareholders? The employees? This could be used as a basis for a small discussion on stakeholder analysis / theory and its importance in defining what a successful software project is.
The following list of stakeholders might be used to further evaluate the Definition of Success for each team (although a custom list might be used as well):
Each team wins 2 points for each stakeholder on the list whom interests are being represented by their Definition of Success.
ROUND III (30 mins)
Part I (10 mins)
Ask teams to go through their list of success factors and mark only these factors which have direct impact on their Definition of Success (they should mark them either green or put a star sign in front of them). Now ask teams to mark these factors which have indirect impact (mark them either yellow or a square sign), no impact (either white or a circle sign) or negative impact (red or a triangle sign). Calculate the points for each team using the following criteria:
Whites / circles are waste / muda (e.g. unnecessary / irrelevant efforts) while reds / triangles are negative influences regarding the Definition of Success. Having whites and reds is a direct result of the Means First, Then States Syndrome and shows how ineffective / inappropriate means / how-tos might be if they are not aligned with the actual desired end states.
Part II (20 mins)
Introduce the agile manifesto and the motivation of its signators. For each value / principle ask the teams whether they could link it to some of the success factors on their list. If yes, how it was marked – as green, yellow, white or red? If no, ask them whether they would like to add it as a success factor. How would they mark it? Which stakeholders’ interests do they represent? Once all the values / principles of the agile manifesto are covered ask teams whether they would like to add new values / principles to the manifesto. If the proposed success factor is accepted by all teams, the team proposing the success factor wins 5 points. No more than 3 proposals could be done by one team.
End (5 mins)
Calculate the results by summing up the points gained by each team and announce the winners.
Original article: http://www.agify.me/means-first-then-states-syndrome/