Tag Archives: process

Only You Care How It’s Built

By agile, philosophy, , , , , , , , ,

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

By 2 commentsagile, , , , , , ,

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?

When Adding Waste isn’t Waste

By 2 commentsagile, , ,

Naresh Jain over at Managed Chaos was griping about The Bloat Effect. The gist is that as time moves on, everything gets bigger and more bloated, including the software, the team, and the process. This makes everything less valuable as a result.

There is often waste in our process. Sometimes it’s given to us and we have to deal with it. Occasionally we introduce it willingly. Often, we start out bloated. We may have an idea of what the streamlined, efficient process looks like, but it’s not what we adopt. Often there are good reasons, or at least reasons. We are, after all, smart, intentional people.

First of all, a definition of waste. Anything that does not directly add value to the customer is waste. Anything that causes you to spend more time than is necessary, is waste. Anything built but not used is waste. Anything that hinders progress is waste. A common goal of any process is to minimize waste, but sometimes we need it. Sometimes waste in the micro saves work in the macro. Waterfall is kinda like this. The theory is that the more you can remove uncertainty with upfront work, the smoother the project will be, ultimately saving time than if the project had tripped over some of the intricacies later in the cycle, or at least having predictable results with predictable resources. Of course, we know how well that usually works out. Agile aims to minimize all of this waste through multiple iterations and is comfortable with whatever revisions may be necessary later on, based on what we learn.

Recognize the role that waste is playing.

If you are being asked to do something you consider unnecessary, find out what need it is filling. If there isn’t one, you may have an argument for eliminating the task. If there is, you may be able to find a leaner way to solve that need. If you don’t have the authority to make the change, you may have to figure out who in the organization can and convince them. Unfortunately, waste is often thrust upon us with no recourse. Then it’s back to a software version of the serenity prayer, accepting what we can’t change and working on what we can. Sometimes that’s just just ‘how it’s done’.

However, you may choose to add steps into your own process to save time later on. If you experience a frequent roadblock that causes a lot of churn, you may need to add extra steps upfront to deal with it. For example, if you have difficulty communicating new concepts to key stakeholders, perhaps more time needs to be spent fleshing out those ideas before they are presented, especially if you believe that they are justified by the business and user needs. Do you spend time that feels unnecessary? What steps could you take earlier to minimize this unnecessary expenditure of effort? Would the trade-off be worth it?

Simplify as you go

Even if you can’t immediately change the process, you can work to simplify over time. Just because there may be legitimate reasons why you live with the excess now, don’t let that keep you from working to improve the process. This is one of the 12 principles of behind the Agile Manifesto. Can you take a small step the next sprint, or the next release, to streamline? Can you keep educating those insisting on inefficient methods in better processes? Is it waste or is it really saving you time later on? People may be hanging on to tools and processes that they are familiar and comfortable with. Moving them away from them too quickly may be difficult or undesirable in the short term. As you demonstrate success, you will have the freedom and trust to make changes and put past process attachments to rest.

Is it Agile?

As you evolve as a team, you may encounter people who tell you that, ‘You’re not Agile.’ They may be right. You may not be capital-A Agile, but I think the key questions are:

1. Are we doing better this sprint than last sprint?
2. Are we making changes that we expect will enable us to perform better in the next sprint?

Adding value

To often I’m concerned less with removing steps than with adding them. It seems common to encounter an engineering team that has been using agile without the benefit of UX and now they are experiencing some pain. There is often the misconception that waste is anything that is not working code. At the recent Deep Agile Conference, James Coplien indicated that, “Rework in implementation is waste, rework in design is agile.” Adding in a quick usability test to uncover design flaws early is not an outdated process to be slowly abandoned. It is a positive practice that should be introduced where it is lacking. Engage with your users, gather feedback on your product/designs, measure your results. These are steps that do not directly contribute to customer value, but they are some key elements that form the foundation of a solid product. Waste needs to be looked at in the context of the entire product, not just the tasks that any one individual or team are performing.