I’ve been on two Agile projects now where the following has worked. Not perfect but it helps to solve a problem that I’m seeing a lot at the beginning of projects. That is, how do you get from raw requirements and use cases into INVESTic user stories and epics?
Think – you’ve got a new product, you’ve got stakeholders in the room; they are brainstorming. They come out with a bunch of requirements. They leave. The dev team now has to figure out how to take this long list and turn it into develop-able requirements. We’ve got a lot of tools for dealing with stories once they are baked; estimation sessions, planning pokers etc. But the tools don’t seem so clear when you are trying to make sense of requirements at the inception of a project. So here’s one way I’ve seen that works:
Assuming you’ve got that list of requirements I mentioned earlier:
Move requirements into Features
Analyze the requirements as follows:
- True Need Analysis – Figure out what the real requirement is behind the ask. This is usually the domain of the BA. What is the user really asking for? For example, they may say they want a button that says ‘eject’ but what they really want is a workflow where they can stop the process at any point.
- De-Duping and Current State-ing – Figure out what requirements are really mimics of each other. For example, one user asks for an ‘eject’ button while another asks for a ‘Stop Process’ button. Merge when possible. Also – it could be that you’ve already built what the requirements are asking for – your current state meets the need. So give the requirements a current state pass as well.
- Grouping and Aggregating – How do requirements logically fit in with other requirements? What requirements are similar enough that they could be parts of the same feature in a product? Spend some time grouping those requirements together and give that feature a name.
- Acceptance – Determine how you’ll know that you’ve accurately completed this requirement. Check the language of the requirement because sometimes the requirements themselves can become acceptance criteria.
Prep the Features in a Spike
To fully Prep requirements, create a spike.
What is fully Prepped? It means that the feature has documented and clarified use cases, user personas who will verify that the feature meets their needs, high level technical specifications if needed, definition of done (preferable with acceptance criteria), and a priority as provided by the Product Owner. Basically it answers what we’re building, who we are building for, how they will use it.
Handover the feature to the development team
Over the past few years I’ve had the opportunity to work on many teams that call themselves agile. While teams can do the agile process, they may not have an agile mindset.
I’ve always held out that agile was a state of mind moreso than a process. More allowing porous flexibility, than stories and iteration planning. As PM transitioning from iterative to agile, it’s been a bit bumpy for me. I’ve wanted too much process, or perfection in documentation – or even too much standardization. Allowing for being agile can feel chaotic (though as an aside, allowing for a bit of chaos is probably where Project Management should be heading ).
I think it helps to re-read the original agile manifesto. It doesn’t talk about user stories, or iterations or task estimation. It talks about a mind set – a mental approach, and a set of values.
I thought I’d share my learning with you. So as a PM, you can have some practical indicators of where your team is with this whole agile mindset thing.
Here are some things a good agile team does:
1. Finds the root cause
AGILE: When a problem presents itself, a truly agile team swarms around the solution. They figure out the problem and then prioritize it. Because they believe that software should be consistently workable, they almost take it personally when it’s not. So they really want to know why something is not working and they spend time to figure it out.
NON AGILE: Non agile teams tend to initiate surface fixes and then save the root cause analysis for a later time. They are not as passionate about finding the root cause.
2. Questions process and documentation
AGILE: Transition to true agile from iterative was a bit of a challenge for me as a PM. I had to get used to people making me justify why something should be documented. Truly agile teams know the difference between documentation that will sit on a shelf and documentation that will help build great software. And they police themselves, and their leadership, to make sure they don’t waste time.
NON AGILE: Builds in on the shelf documentation into the process because they believe they have to do the work. In other words, they don’t really question authority in this regard.
3. Doesn’t update jira/rally/asssembla that well
AGILE: Another pain point for me, which I have accepted will always be a pain point as a scrum master, is that status updates to story tracking systems is going to be light. I cannot tell you how many times I’ve commiserated with other scrum masters on this point. Better to just accept it and send out the weekly/status – please update your stories/points email.
NON AGILE: Focuses a lot of time on status reporting. Tends to fill out all the fields in the story tracking system. Tends to also then assume that an status email/report must also be filled out.
4. Wants product owner approval
AGILE: Agile teams hesitate if you suggest that you just push code without PO approval. A good agile team trusts, respects and wants the approval of the PO – because that enables them to produce a good product. This is part of the process they actually want to stick to. Even if a release is held up, the agile team will wait for PO approval; schedule be damned.
NON AGILE: Non agile teams tend to push code according to a schedule. The PO had better get on that schedule or they will miss the demo opportunity. In other words, schedule trumps PO approval.
As thoughtworks empahsizes so well, its the differnce between Doing Agile and Being Agile
5. Handles changes without a lot of theatrics
AGILE: Change is welcome. There’s a positive inclination to take a minute and be open, respecting the change as legitimate. This team believes that change is ok – so they have a process built already for efficient processing of changes, and they throw the change into that process.
NON AGILE: Non Agile teams have a process that slows the review of the changes. It’s not an immediate understanding, review and prioritization. Instead you’ll see a change go immediately to backlog. The backlog then grows and grows until no one understands or remembers why something was put there. Then the theatrics begin with the client, who is wondering -> what happened to that thing I asked for – I’m still seeing this bug?
6. Gravitates towards bite sized chunks
AGILE: Agile teams don’t accept large chunks of work. They will scrum around something big and break it down into small chunks.
NON AGILE: Breaking down a task means a) that you can hide within it and b) other people can’t pick it up. So non agile teams accepts a large chunk of work and won’t try to break it down.
7. Consistently tries to figure out how to make things more efficient
AGILE: Agile teams ask the question; how can we be more efficient, faster, more productive. They tend to revisit infrastructure, metrics on systems and incorporate automation into the process (like build servers and CI).
NON AGILE: Tends to revisit infrastructure, efficiency, metrics questions when things stop working or slow down to a crawl.
An Agile mindset is just that – a state of mind, a set of values. Its a constant questioning, and an opening up to possibilities. Its a predisposition to produce great things.
Take some more time with this presentation from Thoughtworks.
Our team recently made a change that reduced our standups from 30-45 minutes to 10-20 minutes.
I repeat: 30-45 minutes to 10-20 minutes.
I guess the key question is – how did we get up to 30-45 minutes for a standup? That’s kind of a long time to stand around!
Well, we started using standup to communicate status. This is even though we have an automated agile board – upon which status should be communicated.
And when 12 people communicate status, ie what I did yesterday, what I’m going to do today – we lose the ability to really communicate about things that need talking about.
The sad thing was that after we spent 20 minutes on status THEN we would start talking about defects, problems, and blockers and pretty much people would be ancy and not really interested in talking and solving problems.
So we decided to pull it in and nail it down to what really needed to be discussed. This was deemed to be:
• Priority Defects – answering: what problems are we facing in our production process/build?
• Any problems with functional test/continuous integration – answering: what problems are we facing in the upcoming process/build?
• Blockers – answering: what’s stopping me from moving forward?
This approach got us talking about things that matter.
We are now communicating what we need to do, and who is going to do it; quickly. The result of our actions (read: status) is reported in the automated agile technology tool (which is what it’s for).
The key is really to move from reporting (which is past focused) to assigning (which is future focused).
I cannot tell you how liberating this is.
Developers get a bad rap from us IT PMs.
We IT PMs have a sort of prevailing wisdom about dealing with the ‘devs’. We even talk about it in our job interviews as a known issue; this idea that Devs are cantankerous arrogant curmudgeons, and we need to have certain skills as PMs to navigate through Dev incurred roadblocks to timelines.
Well, I’ve worked with and been friends with Devs for a long time and I think it’s time we think a bit differently about them. From what I’ve seen, Devs have always been good to me (made deadlines, stuck to process, built incredible things) when I’ve thought of them, and given them high regard.
I think any PM will see an improvement in Dev-Pm relations if you remember and adapt to the following:
Appreciate The Knowledge
Developers are like skilled artisans; people who shape, and mold an idea into something concrete, movable, usable. We respect someone who, for example, builds a beautiful table, because we understand that the ability to merge art and function is unique and rare. Perhaps because there is so much work, and so many developers, we tend to down play the work they actually do.
With an artisan point of view, we should approach developers with an appreciation for their knowledge. This attitude manifests itself when we interpret questions around requirements not as stone walling, but instead, a desire to build the best thing possible.
Artisans tend to develop a sense of pride in their creation. We should recognize that when we shift gears too suddenly in requirements, that thing in which pride was taken, has to be tabled. There is some kind of human cost to this, a disappointment. Multiple disappointments can lead to bitterness. As PMs we should recognize this sensitivity. Our role in controlling the process and QAing and ensuring good requirements is key to minimizing this phenomena.
Trust the Delivery
I approach that edge of the full elaboration of requirements and the beginning of the magical transformation into something functional carefully. As a team, we want to explain the design, but relax and step back slightly to allow the technical ability to form idea into function to show itself and flourish.
I think a lot of PMs have a hard time letting go at this point. We often want to know the exact details of how something will be built. So we have to employ trust and allow the development team to prove that they can deliver. Paradoxically employing trust, even if things arrive a little late, serves to open up the channels of communication about the details.
I learned this directly from a dev manager when he suggested that instead of questioning why something was done by a certain date, I instead inquire about the complexity of an item. The implication of ‘is this more complex than originally thought’ is that the developer is doing their job. The implication of ‘why isn’t this done’ is that the developer is not doing their job. Subtly of approach respects the individual and lends towards a better delivery.
Give em a say in the Process
Contrary to popular belief, I think most developers actually like process. I’ve worked with dev teams who’ve initially resisted process become dev teams who champion process. The win for the developer is when process produces good requirements, be they requirements documents, or super clear user stories with well thought out acceptance criteria. The other win for process is when the process keeps WIP at some kind of sanity level to allows the developer to do the kind of work they take pride in, and the team to trust the delivery. Monitoring both – clear requirements and scope sanity – will be an immediate win to reducing barriers to process.
Especially when it comes to code migration process, we can really engage developers. Let them create the process while providing guidance that the process should be simple, clear, clearly elaborate roles and serves to ensure traceability. PMs can help by then documenting what the developers agreed to, helping to shore up any holes in the process, and then acting as an oversight on that process. The key is it’s their process, not something that was dropped on top of them.
Course, those three things, appreciation, trust and communication are the basis of all good human interaction. PMs, let’s do what we can to make sure that when it comes to developers, we employ these tools to become partners, not antagonists.
I used to think that it was just me. Like I would go into new project environment and feel like ‘ugh’, the human emotional soup was all gross and thick. People were so mean on one project that when I tried to bring two representatives of opposing groups together, as soon as the IT rep walked in the room, the business PM yelled ‘WHAT IS HE DOING HERE!?’.
Is it possible to really have a successful project when there’s nothing but human muck flying around?
I never thought so. And now a new study suggests that yes indeed, there is such thing as a ‘feel’ to a project…they call it the Project Spirit. And there’s some data to suggest that a good Project Spirit will result in Project Success.
This seems a little common sense….HOWEVER. There are still people that believe that a) people have to do their jobs, and b) they have to bone up and have tough skins and not be so sensitive and c) none of this emotion stuff affects how the job gets done.
WRONG – the emotion stuff absolutely does affect the project.. absolutely does.
Here’s more on that…
Project Spirit and Project Success
I like this idea of Project Spirit.
Seems kind of hokey at first, but according the February 2013 PM Journal article “Managing the Intangible Aspects of a Project: The Affect of Vision, Artifacts and Leader Values on Project Spirit and Success in Technology-Driven Projects” by Aranson, Shehar, and Patanakul, Project Spirit is actually a thing that can be measured.
Basically Project Spirit is:
- Behavioral Norms
…0f the project participants.
The article suggests that certain activities, which they call Leader Building Activities, affect the Project Spirit.
These activities are defined as:
- Vision, and the ability of the leader to articulate a vision that people want to follow
- Values, and the ability of the leader to instill their positive values into the project team
- Artifacts, the rituals and symbols of the project
The causal relationship is that the Vision, Values and Artifacts (Leader Building Activities) affect the Emotions, Attitudes, Behavioral Norms (Project Spirit). FInally Project Spirit affects what the authors describe as ‘Contextual Performance Behavior.’
“Contextual performance behavior involves voluntarily assisting coworkers in various ways, taking on additional assignments, keeping a positive attitude and tolerating inconveniences at work. Contextual performance behavior generally has two common themes: It is representative of the employee’s extra efforts that contribute to productivity, and it is not directly enforceable, meaning its is not technically required as part of one’s job“
And it’s this contextual performance behavior that can affect project success.
The authors set out to prove that “Project Spirit positively affects contextual performance behavior” by analyzing NASA Mars projects.
Mars Pathfinder, a succesful project, was one where Project Spirit was managed through setting a clear vision, management that set an example through their own tone and behavior (values), short effective meetings, team happy hours, colocation (artifacts). The vision, values and artifacts resulted in a team that had a certain sense of excitement (emotions), a commitment to the people on the project (attitudes), and high spirited group of people who valued honesty (behavioral norms).
Mars Climate Orbiter, a failed project, was one where Project Spirit was not managed. The vision was driven by cost savings,
management “lacked a balance between confidence and arrogance”(values), a sense of the need to build a “protective shield to outside option..or expert involvement”, a leadership that lacked a ‘collegial relationship with team members’, and a team that was not co-located (artifacts). Emotionally the team was very invested in success (emotions), resulting in an attitude to devote “lives, weekends, and time” (attitudes), and a “diminished culture of inclusion” (behavioral norms). This resulted in an over taxed workforce who weren’t open to outside input that could guide the project (behavior outcomes).
The project that set a positive emotional tone through clear vision, people-affirming values, project rituals and symbols resulted in a place where people felt excited to do their jobs, and went above and beyond what they were supposed to do, was a clear success.
So yea…it’s not just you! There is a feel to that project, and as a PM there are things you can to do start to change that context and bring in a positive Project Spirit through setting clear vision, instilling positive values and setting up artifacts that build a sense of team. Read the article for more ideas.
Side note: I’ve been on a Battlestar Galactica jaunt and if you want some good examples of how to do this, watch President Laura Roslin and Admiral Adama. They do this really really well. Adama is always instilling values, Roslin is always insting on rituals to build morale, and together they build a vision to get to Earth. Somehow they build a positive Project Spirit in a really bad situation.
Today I’m inspired by Andrea Brockmeier and Elizabeth’s Larson’s article in Project Times concerning 2013 Trends in Project Management.
“Project professionals need to provide advice, not pushback. Several years ago organizations told us that they wanted PMs and BAs to be able to push back when their stakeholders asked for new requirements. Some of these organizations are now seeing that pushing back is one way to avoid being an order-taker, but it is less effective than providing well-analyzed advice. Our prediction is that more organizations will want PMs and BAs to be trusted advisers (sometimes called trusted partners).” from http://www.projecttimes.com/elizabeth-larson/2013-trends-in-business-analysis-and-project-management.html
I would just like to add on to this idea.
Over the past couple of years, I’ve run into Project Managers who are expert Push-Backers. I think a lot of them don’t really know what advice giving really looks and feels like. I think that they are so used to being ‘IT’ that they adopt push back as part of the culture. I have at times been a push-backer but fortunately I’ve had really painful experiences that have forced me to be more of an adviser. So having sat on both sides of the fence I decided to write up a few things that indicate to me what an adviser looks/sounds like vis what a push-backer looks/sounds like.
Here we go:
Investment in the Solution
The IT Adviser PM:
You’re not really that invested in the solutions proposed. You care, because you want the best thing for the project, but if the wrong decision is made, you feel that you’ve given it your best shot and that’s it. You recognize that giving all the info was your role, the decision was not your role.
The IT Push Backer PM:
You are absolutely invested in the solution you’ve presented. You feel emotionally distraught if things don’t go the way think they should. You think any decision that is different from the one you’ve already made in your head is wrong.
The IT Adviser PM:
When you listen to solutions or directions other than your own, you really listen. You’re open, you consider, and you build on what you’ve heard.
The IT Push Backer PM:
When other people give their ideas, you look for ways that those solutions won’t work. You are vocal about how those solutions won’t work.
Respecting Others Knowledge
The IT Adviser PM:
You think that business people, even though they aren’t as knowledgeable about systems as you, should be given respect for what they know about their business domain. There are things you recognize you don’t know, and you are open to learning.
The IT Push Backer PM:
You think that business users should pretty much stay out of systems. You know the system, you know how it works, and they don’t need to know too much about how things work. Business knowledge is important, but only to the extent that it results in good requirements/user stories.
The IT Adviser PM:
You think about what could go wrong because you want to make sure that the solution succeeds. You bring it up and talk proactively about risks, and you give business users a way to discuss risk without it being personal.
The IT Push Backer PM:
You think about the solution as an IT solution. Anything that happens outside of IT must be resolved by business users. One major risk that you see is the business not having their act together and wasting your people’s time. You actively guard against this risk.
So which one are you? Chances are you’re a little bit of both. Chances are you have to shift between a continuum that has adviser on one side and push backer on the other depending on who you’re dealing with. But if we are to look at the trends, as suggested by Brockmeier and Larson, it can’t hurt to take a personal time out and think about how you can develop some refined adviser chops for the future.
December 15, 2012 Making Theory Usable: Tips to Go Beyond the Lesson Learned and Really Change Behavior
- Sometimes we reflect
- Sometimes we use metaphors
- Sometimes we have constructive conversations
- Sometimes we assess our impact
There is new research that suggests that if we are able to combine these modes of communication into one game like activity that’s fun and intuitive, we can help our teams communicate more effectively. Dr. Arthur Shelley is developing these ideas in his Reflective Performance Cycle (RPC) and wrote about it in the most recent PM Journal (December 2012).
Metaphor is defined as: A thing regarded as representative or symbolic of something else, esp. something abstract. Using metaphor helps to enable people to talk about behaviors in a way that separates the person from the problem.
Reflection is something we already do in the lesson learned, where we think back and analyze what happened in the past.
Constructive conversation is when you use the conversation to achieve an outcome. In other words constructive conversation is a discussion of a subject upon which, at the end of the conversation there is a decision or an action in relationship to that subject.
Impact is something we touch on in the lesson learned sometimes, but this article suggests that we role play and pre-evaluate the potential impact of behavior, before we engage in that behavior.
This makes me think about how I set up meetings, aka what-I’ve-learned-to-do-from-leading-crash-and-burn-meetings in the past. When I set up meetings, I always describe the behavior and the method of the meeting. So for example, I might say:
This meeting is to discuss the most recent production push. Please think ahead about those things that worked and those things that didn’t.
We are going to:
1. Discuss what went well
2. Discuss what didn’t go well
3. Brainstorm ideas about how to shore up areas that didn’t go well
4. Decide which changes we can make right away
I think that most agile teams build this type of reflection in with a standard sprint retrospective. But what I’m talking about here is setting up the desired behavior that you want from the team, in advance. By sending a message like this before the meeting you are:
- Using a metaphor, brainstorm, to describing the way the team will interact.
- Describing the desired behavior from the team. We will think, we will describe, we will decide.
- Asking for reflection ahead of time: please think ahead about these things.
- Indicating that the conversation will have an outcome; therefore it will be constructive: decide which changes we can make right away.
This type of message engages the human brain in setting the stage. I’ve found this setup to be really useful in getting the desired outcome that I’d like.
But here’s the meat of the matter
The article provides even more delicious ways to engage your team by combining behavior, reflection, constructive conversations, and impact assessment.
One activity that I believe shows promise can be run with a team where “participants can pre-select which behaviors are the the most appropriate for achieving the desired outcomes of each
conversation, depending on the situation” (Shelley, PM Journal, December 2012, Page 89).
I could see an IT team using this to help smooth communications with their business stakeholders. This activity would be done without the business stakeholders.
In the activity, a deck of cards is used. Each card has a type of animal. Because of cultural conditioning, we all have ideas about animals and what they represent. The lion for example usually represents decisiveness and bravery. While a snake usually represents sneakiness.
Shelley describes this activity:
“The nine members of the group were asked to (Individually) use the cards to profile at least one of their stakeholders with a view to understanding them better.
They were instructed to consider how they should behave in order to secure their desired outcomes from the next interaction with the stakeholder.
Before engaging with the stakeholder, participants were encouraged to role play the planned interaction or at least discuss it with peers.
[Other] participants were asked to record and challenge their thoughts regarding the interaction with the stakeholder in a reflective impact diary template.” (Shelley, PM Journal, December 2012, Page 90).
Breaking it down, the activity goes like this:
Using a metaphor for behavior (the cards) describe the behavior of a stakeholder.
ex. “The project sponsor is a Pirana. Everytime I go to talk to them, its like a feeding frenzy, they jump all over me with everything that could go wrong.”
Think about the next interaction with that stakeholder and consider how the team member should adjust their behavior in order to get the desired outcome.
ex. “I could not jump in the proverbial water! Perhaps if I prep myself by considering the good and the bad that could happen ahead of time, and then approach them with a more complete analysis, I’ll pre-empt the strike.”
Role play the new behavior.
One team member plays the stakeholder. The team member would practice the new behavior while other team members record the interaction.
Reflect on the role play and assess the impact of the change in behavior.
The observing team members share their reflection of the interaction, and adjustments are made.
Check out Dr. Shelley’s slideshare presentation to learn more: