Tag Archives: scrum

Only You Care How It’s Built

Remember the last time you were really frustrated when using something? It didn’t work as you expected or you couldn’t find what you were looking for. As your attention focused on the people who built the tortuous tool, do you remember thinking to yourself, “That’s OK. I hear they have a great process.” No? The unfortunate truth is that the people you are building for will not care how you got there, only whether you solved one of their problems in a positive way.

I think this is one of the reasons behind the first agile value, “Individuals and interactions over processes and tools”. It is tempting, when integrating new practices, such as with scrum, to get caught up in the mechanics of a new process. There are new ways of working and new tools to learn, and these can take a lot of time, energy, and focus. It can be tempting to do things ‘by the book’ when first starting out, but that puts our focus on the wrong goal. The team is not there to perfect a process, but to deliver value to real people.

So why “Individuals and interactions,” and not “results”? Results don’t make a product, people do. The people are the invisible force that create the product. As one of the agile principles states, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

Pixar’s Randy Nelson has a fantastic definition of collaboration not as cooperation, but amplification. A good team that works well together will amplify each others’ skills and abilities to create better results than they would as individuals. This definitely resonates with my personal experience. My best ideas usually come when I’m engaged with others, not when I’m by myself. Sure, I have a few Eureka! moments wearing headphones, pushing pixels, but the bulk of them come from the interaction with other minds approaching the problem from different directions, each with their unique personal history.

There are many elements that create an environment that a allows a team to succeed. As implied above, clear goals and measurable results is one. I’ll go into that and a few more in a future post. In the meantime, what is it about your environment that supports or hinders your team? Do you have motivated people? Do your stakeholders trust you to make decisions on their behalf? Are you focused on value? What have you changed about your environment that has had a positive impact?

As always, I look forward to your comments. Also, please take a moment to rate this post by clicking the stars below the title. It helps me know if I’m on the right track and I really appreciate the feedback. If there is a specific topic you’d like me to address, add it to the Suggest a Topic page.

Going Back to the Source: The Agile Manifesto

There are a lot of different ways to implement agile. That is one of its strengths. Agile allows you to create exactly the process that works for your team, company, problem, and client. However, it also gives teams the responsibility to create that process, and that is difficult. Teams typically can’t rely on doing things the way they’ve always been done.

Whatever practices are put in place, be sure that you are true to the agile values and principles. I’ve been interviewing with many companies over the last 6 weeks <shamelessPlug> (I am available for work in the Boston area) </shamelessPlug> and I’ve been surprised at how many people are talking about agile, have not read the manifesto, and think that agile is about sprints, daily meetings, and a lack of big upfront design.

Agile is 4 values and 12 principles. Period. It doesn’t say whether to do upfront work or not, or to work in sprints, or to have backlogs, or to start coding right away. These are techniques that some teams have used based on agile, and others have codified into practices such as scrum, but these practices are like the reflection of the moon in a pond. If the water is choppy, the reflection is broken and unrecognizable. If the water is still, the reflection is very clear. Yet, as alluring as that image may be, it is still not the moon.

If you have never read the manifesto or haven’t in a while, do it now. Really. Go. I’ll wait. It’ll only take a minute.

Back? Great.

One of the values is “Working software over comprehensive documentation”. It doesn’t say don’t create documentation, but place a higher priority on working software over comprehensive documentation. Focus your priority on creating something that works more than an exhaustive description of something to build. Make sure that the documentation the team chooses to create has lasting benefit.

The values are not absolutes, but relative statements. If you adopt practices associated with agile without understanding the conceptual underpinnings, you may find that you are not getting the effect you hoped for, or maybe there are better practices that would support those values better given the unique situation of your team. A team that adopts the practices without incorporating the principles will be like like the moon’s reflection on choppy waters. It will be tough to see a coherent vision of what is being done. A team that chooses its activities based on how the values fit them will be like the reflection in a still pond.

For me, one of the most evocative parts of the manifesto is the last principle, “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” That alone, is worth the price of admission.

Please take a moment to rate this post (under the title) and leave your comments. Which elements of the manifesto does your team most embody?

Adopting Agile is Hard

Before getting into the details of our particular challenges, I wanted to acknowledge, for all of you going through this, that adopting agile is hard, perhaps one of the biggest professional hurdles I’ve faced in recent history. While I’ve been in the same industry for about 12 years now, I imagine this is about as close as you can come to switching careers without actually doing it. You think you know what’s going on, but the rug keeps getting pulled out from under you. However, I also like the term ‘adopting’ because this is similar to adding a child to your family.

When you have a kid, your life is no longer the same. You’ll sleep less. There will be lots of screaming, and you will have to clean up more crap than ever before. Moving to an agile process seems a lot like that. The hope is that once you figure it out, life is better and you wonder how you ever lived without it.

Even reading about agile can be as confusing as negotiating the parenting section of a bookstore. Want to know how to get your baby to sleep at night? Here are 20 books that all say something different. Want to adopt an agile process? Here are multiple options, each with different interpretations.

To be fair, the looseness of agile, and scrum in particular, is one of the things I like most about it, and what also causes the most pain. If you were to ask a personified scrum process what to do, the answer would likely be, “It depends.” It may be true, but it doesn’t feel helpful.

Agile is more of a philosophy than a process. It dictates very little. We have five scrum teams working concurrently and each one works a little differently. One team has a number of outsourced members across the globe. Two others are working on entirely new initiatives The last two are refining existing parts of the site, although they move from making small tweaks to significant additions or revisions. Some teams do more costing and planning for each sprint, while others are very loose. Each of these teams have developed their own idiosyncratic scrum process that works with their unique situation. This is one of the powerful elements of the agile methodology, the flexibility. It is also one of the biggest challenges. Teams must define their process for themselves. Scrum only provides a framework. Each team is trying to do what is best for their people and their project, but it can be very difficult to work across multiple teams that are working differently.

There seems to be a sense of the serenity prayer to it. Agile is a new process and will require a lot of change. However, realize what you won’t be able to change and find a way to work within those constraints. I appreciate that this process acknowledges the realities of organizations and attempts to work with them. I found Ken Schwaber’s book Agile Project Management with Scrum very helpful in demonstrating this. In this book, Ken presents case studies of teams in different circumstances at different companies. In one case study, knowing that the program management office required Microsoft Project files for status reporting, the Product Owner adapted scrum reporting to fit within Project’s framework. Rather than trying to get another part of the organization to adapt in a futile battle against the windmills, teams in this book found ways to improve their process while working with the constraints they had to live with.

So if this feels painful or impossible, that’s normal. It means that you’re going through change. Recently, our Program Manager and resident certified Scrum Master attended a conference with two major agile gurus. After listening to the other people describe their problems, he says that he came away feeling that we are doing quite well compared to a lot of other companies! Given how hard it has been for us, I really feel for those who are not quite as far along the path.

As we figure things out, I’ll share what I can. Until then, if you have any questions, I may respond with, “It depends.”

If there is something particular that you would like me to write about, visit the Suggest a Topic page. You can vote on existing topics or add your own. I’ll do my best to address them in a reasonable time frame.