Nailing Down the Vision

I’m proud to be a contributor to AtTask’s new Lessons Learned Tome Project Leadership Lessons from 40 PPM Experts 

My contribution is to Nail Down the Vision.

Easy read, with clear good lessons sourced from real life.  Check it out!

 

 

 

 

One way to bridge the gap from raw requirements to user stories

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:

1. 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.
2. 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.
3. 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.
4. 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.

You’ll come out with a not fully baked list of features which you can go take back to the stakeholders for verification.

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 

Usually this is accomplished through a separate spike meeting, with a presentation of the findings. Following the handover, the dev team should be able to breakdown the feature into epics and stories and the (currently well documented and doesn’t need to be rehashed here) Agile process takes place.

How are you handling this move from raw requirements into epics and stories? 

It’s a state of mind: Some practical indicators on doing agile vs. being agile

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. 

An Agile state of mind

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, it’s the difference between Doing Agile and Being Agile

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.

 

Shorten your Standup

Standup used to feel like this

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

Feels a bit more like this now

 

I cannot tell you how liberating this is.

Loving the Devs OR A Little Appreciation and Trust Goes a Long Way

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

Requirements become design and merge with the human skill of the builder/artisan to become something usable and beautiful

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.

It’s ok…let go!

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.