Category Archives: agile
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.
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.
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?
According to Clayton Christensen in The Innovator’s Dilemma, markets for disruptive technologies may not be known prior to release and therefore often cannot be planned for. Where does that leave UX? How can you do research if you don’t know who to talk to? How can we do any user-centered design if we don’t know who the users will turn out to be and how they may use the product? So what is the value of UX in an early stage start up or similarly innovative team?
While he doesn’t say so explicitly, his research seems to favor an agile approach. Constantly evaluating the product to determine who is using it and what value they are deriving will allow a team to focus their efforts on the goals most important to this new found audience.
This points to two clear uses for UX in the early stages of the creation of a disruptive technology. The first is to give the product the best chance of success by inc0rporating design standards and best practices. The second is in researching the new population of users, their activities, goals, and behaviors.
You only get one chance to make a first impression. Leveraging interaction standards will help give a new product the best chance for a positive initial reaction. Design standards may not work for everyone. They are, by definition, generic. However, it will make the product most likely to be usable by the broadest possible audience. In addition, while aiming for ‘just barely good enough,’ make sure that there is a shared definition of the level of quality required and that there is a UX component to that definition.
Once the first release is live, analyze the user activity. Reach out to some of the most active users. Talk to them about what they love, what they don’t like, how they found out about you, etc. Keep probing each answer for more detail. Find some users who signed up but never became active. What made them interested initially? How did they find using the product? Why did they stop? See if you can define the gap that prevented them from becoming active users.
Once similar stories of real people deriving real value begin to emerge, then we can start to leverage familiar UX tools to move beyond best practices to create a tool that supports the unique needs of those using it.
Having UX involved from the beginning will help you recognize the market when it emerges and be ready to meet its unique demands.
Share your experiences designing new or disruptive technologies. When was UX involved? While you’re at it, please rate this post using the stars beneath the title.
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?
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.
As Tim correctly pointed out in his comment on the previous post, waterfall doesn’t exactly have a stellar record of success. In my experience, a major cause for that is shortchanging the upfront research that is necessary to ensure the success of subsequent stages of development. As I said in my comment, often the proper upfront research that would shape the vision of the product based on business need and customer understanding is sacrificed to meet aggressive deadlines and tight budgets. It’s no wonder that the final product is underwhelming, despite the best efforts of everyone on the team.
If these prior adventures in development have failed, why not try something radically different, like agile. If the organization is not willing to put the effort into a proper upfront research and design phase, then build something and hope you get useful feedback on it, right? It sounds good, but then why do we still find some of the same problems?
Tim hit it again. Often customers, or users, can’t tell us what they want, even when we do ask, or what they say they want is not the best way, or even a good way, to solve their problem. This can happen in waterfall or agile. Customer requests come from their perspective, which is via their domain expertise. They are experts at their tasks, but we are supposed to be experts at designing interactions. The key is to understand the problem and solve it, not just implement what our users request. Maybe the users’ suggestion is spot on. At the very least, these suggestions tell us where to focus our attention. We’ll likely find where pain can be removed or gain can be added. But when it comes to designing the solution, we need to bring our advanced knowledge of computer interactions to bear and conceive of the best ways to address their needs which may be better than our users could imagine.
While working on a call center application, I spent many hours sitting with agents, listening in on customer calls, and observing how they worked. Between calls, I asked a lot of questions about what I heard and what I observed. After only a day or two of this, I had a very good understanding of what their work was like and what their challenges were.
When I asked them what they wanted, they typically mentioned incremental improvements to their current tool, an old ‘green screen’ mainframe application. In fact, when asked if they wanted digital catalogs to replace their large rack of physical catalogs, they categorically said ‘no’. They wanted things similar to how they were. As one agent put it, “I don’t like change.”
However, the time I spent with them plus my understanding of the business challenges led to a radical design in a Flex environment that was light years ahead of what they were used to, and it did include digital catalogs. So how would the agents respond, especially given that we did something they expressly said they didn’t want?
We tested a rough prototype with a handful of novice and experienced agents. The feedback was overwhelmingly positive. At the end of the hour usability test, even the woman who didn’t like change wanted to know when the system was going to launch. She felt it was a dramatic improvement over what she had been using, and had mastered, over the past 13 years as an agent.
So do talk to your users. Ask them what they want. But when it comes to defining the solution, remember that you are expert when it comes to building tools. Just be sure to test your design to make sure you got it right.
To see the comments, or to add your own, click on the little speech bubble below. To subscribe to this blog using RSS, click here. Also, be sure to check out the Suggest a Topic page to vote on future post topics and to suggest your own.
Fast, good, and cheap. Pick two.
This is the familiar instruction represented by the project triangle. A project that is of high quality and delivered quickly will be costly. One that is done well with limited resources will likely take time. An inexpensive project delivered quickly will suffer in its execution. Keeping this in mind, compare waterfall with agile.
Waterfall demands a certain level of quality. All of the upfront research and design, as well as the many gates and checkpoints insure that when the product is released, it meets the expectations defined up front. Waterfall projects can be good and fast, or good and cheap, but the underlying notion is good. Now, experience tells us that the definition of ‘good’ can vary greatly on waterfall projects. ‘Good’ can mean that the end users find the product useful and usable, or that the project is predictable, i.e. that the budget is met with the expected scope, or that the target date is hit and the expectations of scope are managed. I’m sure each of you has experienced many variations on what stakeholders consider ‘good’.
Agile chooses fast and cheap. Sprints are short and teams are small. There are many good reasons for this. They are well documented elsewhere, and include getting working software to users faster, being able to address high priority problems quickly, and abandoning features with little value. With this approach, the mantra for each sprint is ‘good enough’. When choosing fast and cheap, what is sacrificed will be quality. At least initially, this may be true, but agile counters this by adding many revisions following quickly on the heels of an initial release. Problems can be quickly identified and fixed in the next release, which may be as little as two weeks away.
This requires a significant shift in thinking for User Experience. It is our job to ensure that the users have something they find valuable and easy to use. We think big thoughts about mental models and context and integrate detailed thoughts on layout and implications. We have been accustomed to defining the entire picture, making sure all the pieces fit, before moving on. It can be very challenging to take one piece of a larger project and just get it to ‘good enough’ while ignoring the rest of the system. We are judged on how the product looks and behaves. Sacrifices made for expediency affect our credibility and reputation.
We also may have different ideas of what constitutes ‘good enough’. To a prototypical engineer, it may mean that the feature is present and functional. For UX, it’s about utility and ease. A product owner may fall somewhere in the middle. Its important for each team to agree on their shared definition of ‘good enough’. If forced to work under the simplest extreme of ‘functional’, we may not be pleased, but at least our target is clear and we know what to work towards.
This change in thinking is a key challenge to successfully integrating UX and agile. One approach is define a rough, high-level vision so that all involved can get a sense of the whole. During each sprint, or prior to each sprint, fill in the details of the pieces, or stories, about to be built. It won’t guarantee that there won’t be rework, but it will help balance the need for holism with the need for speed. If you don’t get it right this time, there’s always next release.
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.
The company I work for has an evolving agile implementation methodology, specifically Scrum. Over the last two months, the User Experience team has been becoming more of an integrated part of this process. It’s been quite an interesting ride and it is far from over.
I’m actually a process person. I enjoy figuring out how to tackle problems and I recognize that the same process rarely works for two different situations. However, I never quite realized how much of a safety net the waterfall process was. While no project uses the ‘ideal’ process, the many possible steps and variations form a comfortable foundation that is the basis for improvisation. There are different activities and deliverables that answer different questions and needs and these form the toolkit that I have drawn on over the past decade.
Agile is very different. While project needs and user needs haven’t changed, how you can approach the problem from within an agile context is very different. Thankfully, there are some smart people who have paved the way, but there are few clear answers. UE wasn’t at the origin of agile and we are a little late to the game.
I certainly won’t say that anything we are doing is definitive, but I will share some of our struggles and what I’ve taken away from it.
Are you ‘agile’? What works and what doesn’t?