Monthly Archives: October 2013
In our previous blogs, we have outlined two key steps to take before you dive into that new project or idea that you are so excited about. Those were: Step 1 – Set your Goals and Step 2 – Define your target audience, or personas. Now it is time for the final step – decide what success looks like and the best way to do that is to write a scene. I wish I could say this was my idea, but it’s not. The smart people at Wharton wrote a great article on this concept called Visionary Leadership: Creating Scenes that Change the Future. The idea is to define success for your project/challenge/opportunity by creating a scene – like in a movie – of what success would look like in the future. We did this at a company that we are consulting with and it was a great exercise.
Write the Scene
Our effort was an Agile implementation at a company with lots of legacy software and its fair share of legacy processes and ideas. We sat down and pretended that we were through the Agile adoption and the core tenets of Agile were alive and well. Our scene involved speedy response to a changing market condition, reprioritization of work, team execution of a new deliverable, finding out that deliverable was not the correct response, immediately incorporating that feedback, course-correcting and quickly deploying a more suitable solution. This scene included management and stakeholders playing a supportive role without judgment, finger-pointing or unnecessary meetings. Sounds like a dream world, right? This was a great exercise because it forced us to think about all of the attitudes and practices that would need to change to make this scene a reality and that was eye-opening.
It is great to have enthusiasm before you start an exciting project. But before you jump in, it is critical that you pause and take a moment to consider (1) the goals you are trying to achieve, (2) the people you are trying to serve – by defining personas and (3) defining what success looks like – by creating a scene.
What is a persona?
This blog is dedicated to personas. For those not familiar with the term, personas first came to be discussed relative to writing software in 1999 when Alan Cooper released his book, The Inmates are Running the Asylum. A persona is a fictitious character that represents an end user that product managers and scrum teams can use to inform their decisions about a product or feature and how it will work.
When you get that great idea, it is important to stop and think about who you are targeting. What matters to them? What will mean value to that persona – specific features, a low price point, ease of use? Using a persona to guide what you will build is very important. But what about using a persona to decide how you will market? This can be equally useful.
It is real now. Our Agile textbook is advertised on the Pearson Higher Ed website. How cool is that?? After many long months of writing, editing, revising, writing more, researching and writing even more – it has become a reality.
Many more details to come but I had to get the news out because it is so exciting!!!
When we get a good idea, it is natural to jump right in and start working. In recent weeks, several people have had so much enthusiasm about their project that they want to dive right in without any real preparation or fully formed vision of what they want. To address this, here is a three part blog series on steps to take before you start. This week’s blog is dedicated to Goals – or defining what you want to accomplish. Part 2 will be defining your target audience and we will discuss personas. Finally, part 3 will define what success will look like by creating a screenplay.
But first things first. What are your goals for the project? Now, many will tell you that you have to define SMART goals – goals that are Specific, Measurable, Attainable, Relevant and Time-bound. I am going to disagree. While SMART goals are great, I don’t think you need that much structure for every project. There is a saying attributed to Voltaire which says “Perfection is the enemy of the good.” I feel like this applies to goals too. You can spend so much time trying to define metrics that are measurable and time-bound that you delay the project or miss a critical window.
One question that comes up often when teams are exploring the transition to Agile is how they are going to handle bugs or maintenance issues. This blog will outline three scenarios that have worked for teams.
1. Building time into the Sprint
Perhaps the most common way that teams deal with unpredictable bugs and maintenance issues is to reserve some time for them within the Sprint. For example, the team can handle 40 story points per sprint, but they only commit to 35 points, so they will have some time available for the unplanned bugs that need immediate action. In some sprints, the bugs may account for more than the allotted 5 points and in other sprints, they may be less but on the whole, the team learns their rhythm and builds in enough reserves to handle whatever may come up.