Wardley Maps for product development

Wardley Mapping is most commonly associated with higher level business strategy. When I’ve talked to people familiar with Wardley Mapping, they’ve been quick to dismiss it as a tool for the C-level suite, not for mere mortals developing products. I disagree. The following will attempt to explain why I find Wardley Maps not only relevant but vital to product development. If you’re unfamiliar with Wardley Maps, I recommend watching Simon Wardley’s 2017 Google Next talk for a good overview. If you want to take a deeper dive, I suggest Simon’s free online book.

Digital Beanie Baby: Husky
Welcome to the future. Digital Beanie Babies. Trade them on your favorite exchange!

Imagine. We’re transported to a time where it seems like anything with the label “beanie” is drawing attention, mostly because a new form of Digital Beanie Babies (DBB) has been skyrocketing in value for over 12 months. An entire ecosystem has sprouted up around the digital critters. In the midst of this beanie bonanza are exchanges launching to enable trading DBB, much like other exchanges exist for trading stocks, fiat currency (e.g. USD), etc. Each new DBB exchange has its strengths and weaknesses.

A few entrepreneurs identify an opportunity to create a new exchange that fills the gaps left by even the most successful DBB exchanges, while also adding a couple innovative features. They’re focused on meeting existing customer needs in a burgeoning market, not building a larger technical “platform” that has aspirations beyond being a very successful DBB exchange. The founders form their startup, get some technical people on board, build a proof of concept, raise funding, and continue building on the vision of providing a better DBB exchange for traders big and small.

But how does the startup know that they should build this product from the ground up?

Product development for this new exchange is focused on continuing the path the proof of concept set – build a secure, fast, trustworthy, and feature rich DBB exchange from the ground up. In such a new market space this seems reasonable. Put together a small, agile/lean development team and continue to build a product that meets the needs of its traders, validating the product as it is built. Lean startup style.

But how does the startup know that they should build this product from the ground up? Are there pieces they should buy? Higher level functional open source components they should adopt? The assumption is made that because DBB trading is a fairly new market it requires building a brand new product from scratch. Besides, many of the most successful DBB startups built their exchange from the ground up. They blazed a trail, this new startup is simply following in the path that’s cleared for them.

Enter Wardley Maps, a way to visualize the evolution of the underlying landscape anchored to the needs of users. When we map out the Digital Beanie Baby trading landscape, including high level components/requirements of a DBB exchange, we start to see that a number of core components of the exchange are available for purchase, leasing, and/or open source. After all, exchanges have been around quite a while in various forms.

Based on the product development approach the Beanie exchange startup is taking, we’d expect to see most of the exchange components and requirements in the “Custom-Built” or “Genesis/Novel” lane, but instead a majority of the core exchange features in development (highlighted in blue) fall into the “Product/Rental” lane or very close to it. What does this tell our startup? It’s telling them that the bulk of what they’re currently developing is something that has (probably) been built before and is available to buy, lease, or simply use (open source).

A common objection I hear at this point is: OK, but what if you’re wrong about the position of various items on the map? That’s quite possible. The potentially incorrect map positioning can drive meaningful discussions as well as further research to either validate or invalidate the position. The beauty with the map is that we’re: A) having the product/business strategy discussion based upon a shared visual aid and context B) able to identify our assumptions. In the case of our startup example, the biggest areas likely up for debate are core components (that they’re creating themselves) like the matching engine, order book, API, web app, etc. Maybe with some further digging the discovery is made that commercial offerings exist, but they’re immature, or expensive, or rigid, or any number of other issues that may make them less viable as options. Maybe we find that certain components are available as products, but are only really suitable for more traditional exchanges, not for those aimed at trading digital beanies. It’s also possible that we discover there are numerous existing components and products that fit our needs and validate the position of those items on the map.

The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Another objection I’ve heard is that what I’m crediting to Wardley Maps is really just another path to market research that any business should already be doing. Possibly, but the map provides a shared context that market research does not commonly provide, as market research tends to end up buried in docs and slide decks. A group of people can look at a Wardley Map together and start to quickly identify areas of alignment, disagreement, opportunity, etc. Those with more industry expertise can be brought in to look at the assumptions on the map and determine if those assumptions are on track or need adjusted.

In our startup’s case, the map identified some potential blindspots in the product development approach. Should the exchange startup be building something from the ground up that is already available for purchase, rent, and/or adoption? Unless the devil is hiding in the details of those components mapped in the product lane, then it’s unlikely the startup should pour further (fairly limited) development resources into those items. 

It makes more sense for the startup to consider focusing its development time and talent on building items in the novel or custom lanes. Or, possibly focus the engineering team on implementing the items in the product lane, become experts on operating those in production (much sooner than the homegrown equivalent would be available), and then discover through real customer feedback what should be introduced on the exchange next. The possibilities the map opens up are much greater than what development teams tend to consider when they’re building a product, such as, should we: Scale back feature X, Y, Z? Reprioritize the backlog? “Pivot” to target only one subset of customer initially? Change our approach to development in order to increase velocity and lower time to market? Reset some or even all of our goals for the MVP? Those are all legitimate options to consider in product development, but they may be too nearsighted and ultimately limiting. A startup is particularly sensitive to this form of myopia, as the business and product the startup is building are so tightly coupled, it can be hard to determine where one ends and the other begins. The Wardley Map provides a higher level view that can help drive lower level product development decisions.

Adding Wardley Maps to a product development team’s toolbox is a valuable asset, even if at a first glance it’s hard to understand how. Mapping is not a silver bullet or even a tool that is immediately easy to grasp, but it’s worth learning. This example only begins to touch on all the nuances of Wardley Maps. There are many other nuggets of strategy gold to be found for those who take the time to learn how to create and collaborate with these maps.

Not about school

Consider this a parable of sorts for those building products. I’ll leave it up to the reader to determine its meaning.

Carl is a senior in high school and has a D in Algebra II heading into the last semester. He wants to bring his grade up to a B so that he can qualify for college scholarships. Quizzes and tests make up 80% of a student’s grade. The other 20% consists of completing homework (15%) and classroom work (5%). Carl’s Algebra II teacher, Mr. Smith, insists that Carl catch up on all his missing classroom work first, even though most of that work will not help on upcoming quizzes and tests. Mr. Smith works with his student to create a rather large yet well-defined backlog of all the classroom work Carl needs to catch up on so they can track his progress together. Carl diligently works on burning down that backlog. He finally catches up on the classroom work near the end of the school year. Mr. Smith pats him on the back. Carl’s final Algebra II grade is a D+.

A remote retrospective

It’s been a while since I last facilitated an all remote retrospective. Below is an email I sent out to the team I’m currently working with to help us prepare for our first “retro” together. We’ve since held the retro and it went well overall, so I thought this prep and guidance might be useful for others to iterate on.

—–

Hi All,

On Tuesday we’re going to have a Project Retrospective (aka “retro”). In my experience, retros are hugely beneficial opportunities for teams to learn and grow.

Please take the time to read the rest of this email. It outlines how the retro will run. In order to make the most of our time, it’s best to come prepared. :-)

Retro Goals

  • Learning jointly – From each other’s different perspectives, feelings, and current thoughts about where the team is at since launching the project.
  • Taking action Based on learning together, we identify where we can most benefit from improvement and take action.
  • Strengthening the team – We’re in this together. By listening, learning, and taking action on what we’ve learned, we develop a stronger bond that is bigger than “just the work”.

Ground Rules

Regardless of what we discover, we understand and truly believe that everyone did the best job he or she could, given what was known at the time, his or her skills and abilities, the resources available, and the situation at hand.

  1. Be respectful
  2. Be present (no phones, no “side chats/conversations”, no browsing, etc.)
  3. Everyone gets a turn to speak
  4. No interrupting
  5. No judgement on feedback (use “I statements“)

Before The Retro (between now and when we meet)

Please take time between now and when we meet to think about the following in relation to your experience and/or what you observed during your time with the TGE project:

  • What you want us to continue doing
  • What you’d like us to start doing
  • What you’d like us to stop doing

You can add your items to this doc, which we’ll use as part of the retro: Google Doc

The Start

Check-in: We’ll go around the call and have everyone provide one word for how they’re feeling in the moment. Have trouble coming up with a word for how you’re feeling? I know I do sometimes! Try this to help identify a word: https://verbaliststravel.files.wordpress.com/2016/01/the-language-and-vocabulary-wheel-for-feelings-verbalists.jpg

The Middle

Part 1) We’ll use the “Before the Retro” section above to guide the initial discussion. What we want to: continue, start, and stop doing. If you haven’t added your items to each area, we’ll have a short time for everyone to add to each list.

Part 2) We’ll go through each item and open it up for questions/clarification. I will do my best to encourage open, focused discussion that honors our time.

Part 3) Everyone gets 3 votes per area to put against the items they think we should take action on now, not later. You can apply more than 1 vote to an item if you feel that strongly about it.

Part 4) Identify the top item in each area and determine next steps (which can be as simple as identifying an owner to drive the action post-retro). …But what about the other items – aren’t they important too? Yes! But focus is key. Just because an item isn’t made “top priority” doesn’t mean it won’t see progress in the future.

I’m accountable for ensuring the 3 items we identified to take action on make progress. Don’t expect miracles. Some things require a a fair amount of determination over a period of time to show results. My commitment is to continue to provide visibility to the items and help move them forward. Expect this to be part of our weekly meetings, even if it’s just a quick update.

The End

Check-out: Everyone on the call gets a brief (30 seconds or less) opportunity to express closing thoughts/feelings now that the retro is at a close.

Looking forward to learning and improving with you all!

Josh

Agile project management in 2017

The Agile Manifesto turns 16 this year. Scrum turns 22 years old. The grandfather of Agile and Scrum – Lean Manufacturing – has been around much longer, nearly 70 years with the advent of the Toyota Production System (TPS). Put in that perspective, Agile project management is not the new kid on the project management block anymore. Odds are good that an organization has adopted (or is trying to adopt) some form of Agile project management in 2017. Not only has Agile established itself as a viable project management framework for technology projects over the past twenty plus years, but the technology used on those projects and the business environment is constantly evolving, and sometimes even changing in revolutionary ways. And so the question must be asked, what does Agile project management mean and look like in 2017?

Agile Defined

Before examining the details of what Agile project management means and looks like today, it’s important to get a baseline of what it is in general. Wikipedia does a good job of summarizing:

Agile management, or agile process management, or simply agile refers to an iterative, incremental method of managing the design and build activities of engineering, information technology and other business areas that aim to provide new product or service development in a highly flexible and interactive manner; an example is its application in Scrum, an original form of agile software development. It requires capable individuals from the relevant business, openness to consistent customer input, and management openness to non-hierarchical forms of leadership.
https://en.wikipedia.org/wiki/Agile_management

While it might be tempting to jump into a rundown of the latest trends in Agile project management in regards to new frameworks, tools, and concepts; it’s important to see how Agile has evolved in relation to its values and principles. The Agile Manifesto serves as our guide. In its simplest form, the manifesto is expressed in the following value statements:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

http://agilemanifesto.org/

Supporting these values are twelve Agile principles, which this article will examine within the context of what they mean and look like in 2017.

Agile Principle One

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

When major software releases were measured in years, delivering valuable software every month via an Agile framework like Scrum was considered a crowning achievement. Fast forward to today where the internet is ubiquitous, as are powerful computers in our pockets. Continuous delivery takes on a meaning all its own, with the goal being that when new features and functionality are done, they’re ready to be delivered. It’s up to the business to decide when to release, not dictated by technical gatekeepers. In practice this can look like Etsy, where continuous delivery is put on steroids and becomes continuous deployment; meaning every successful build through the delivery pipeline is released into production immediately. This approach can mean new releases go out 50 times a day! It can also look more conservative, yet nonetheless impressive, like the HP LaserJet Firmware division’s move to continuous delivery that resulted in overall development costs reduced by ~40%, programs under development increased by ~140%, and development costs per program dropping by 78%.

Agile Principle Two

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Welcoming changing requirements has become more important in an ever faster marketplace where the hottest product today is tomorrow’s Blackberry phone. Even when businesses have a laser like focus on planning, customer’s needs and wants can seemingly change overnight. This need for near instant change of direction doesn’t mean a lack of planning, but rather the discipline to plan early and often; adapting to the feedback customers are providing. Roadmaps are still necessary, as we all need maps to understand where we are, what the terrain around us is, and where we’re headed. The path we take to get to the destination may (and likely will) change, but we still use the map to get there. A constantly groomed product backlog that aligns with the roadmap is a critical element of Agile project and product management in 2017. The backlog is like the turn-by-turn directions to the roadmap’s line drawn across the landscape. Both need to adjust to an ever changing environment.

Agile Principle Three

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

Much like the first principle, the time to deliver working software should be getting shorter, not longer. The only way this is possible is to have the right level of technical automation (testing, builds, deployment, etc.) combined with tight collaboration across the various roles required to build and deliver working software. There is also a need to breakdown features into small enough pieces that can be delivered frequently. There is a high level of discipline and skill required in order to cut problems into smaller deliverable slices, both from both a technical and business standpoint.

Agile Principle Four

Business people and developers must work together daily throughout the project.

This principle can be construed as one only for startups, where the image of a small team working out of someone’s garage building the next big thing is romanticized. There is a common misperception that enterprises have drastically different needs and therefore can’t have business people collaborating daily with developers. Due to the need for delivering faster, tighter collaboration between business people and software development team members is greater in 2017 than it’s ever been before. In fact, the lines between business people and developers is blurring evermore, as the technology becomes more prevalent, business people feel the pressure to become more technically literate, and developers realize there is a difference between “coding” and “software engineering,” which means developing with the business in mind, not only the technical problem at hand.

Steve Jobs hiring smart people quote

Agile Principle Five

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

It may be easy to dismiss principle five as common sense. Of course you want motivated individuals who have what they need to get the job done. However, there was a trend in the 2000’s to outsource anything tech related in mass. This often resulted in contractual relationships where individuals were seen as not much more than “headcount” or “resources” to be shuffled on a spreadsheet to make the numbers work better for one side or the other. Project teams, whether in-house or outsourced, need to be made up of people who are motivated, aligned, and trusted to meet the goals of delivering valuable software quickly and consistently. Smart organizations in 2017 understand the importance of people and the need to provide them with a healthy environment that motivates them and engenders a high level of trust in order to deliver valuable solutions for customers. It doesn’t matter if these people are sitting in the same building together or halfway around the world working under a contract – the same principle applies.

Agile Principle Six

The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

With more organizations employing remote workers and teams spread out across the globe, this principle is being put to the test more and more as time goes on. The days of hiring for one specific location so everyone can collaborate in the same physical space are dwindling. The advances of technology and the need for businesses to hire the best people regardless of their location translates to the need to work effectively in a distributed fashion. Organizations that take a “remote first” approach to the way they operate stand the best chance of making this work, where the tools and culture are in place to support working across multiple locations. And even though the “7% rule” (where it’s said that only 7% of communication is conveyed in the actual words said) has been debunked, these same organizations will also recognize the importance of spending time in person, and provide resources to allow project teams to gather in the same physical space in order to encourage team building that cannot occur any other way.

Agile Principle Seven

Working software is the primary measure of progress.

Gone are the days of measuring the individual phases of the software development lifecycle (SDLC) as a meaningful form of conveying progress. Working software takes precedence because working software can be used by people, and that means people can provide feedback on how valuable they find the software. The growing adoption of minimum viable products (MVP) in even large organizations only makes working software as a measure of progress that much more relevant.

Agile Principle Eight

Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

The only way to continuously deliver a product is if the approach is sustainable. This doesn’t only apply to technical decisions but how projects are managed; including how teams are formed and developed over time. Project management that places too much overhead (in the guise of being more disciplined) on individuals will not promote a sustainable development model. An example of this is the organization adopting Agile coming from a strict waterfall approach. What was once deemed necessary may no longer be so, but, due to cultural influences, may be enforced just as strongly as before regardless of its effectiveness. On the other side of the pendulum swing, project management that maintains little discipline will also not provide a sustainable model of development, as people will burnout trying to make up for a lack of consistency in how the project is managed. Examples of too little discipline can be found in organizations where there is a culture of celebrating cowboy heroics and never ending workdays.

Agile Principle Nine

Continuous attention to technical excellence and good design enhances agility.

The world of tech and software is not getting simpler in 2017. The rapid change of pace in both technology and business requires agility, and the only way to become more agile is through a continued focus on sound technical design. IoT, big data, artificial intelligence, machine learning, microservices, apps measured in the millions upon millions of active users, etc. are all technologies that are currently hot and adding to the capabilities as well as complexity of products. As mentioned earlier, HP LaserJet Firmware is a good example of an organization that refocused its attention on technical excellence and design in order to enhance their agility. The legacy platform they were building on made it difficult to move at the speed the business required. New product rollouts and features were delayed due to a technical foundation that made it impossible to respond in a timely manner. By putting in place the design, technology, and automation to deliver continuously, HP LaserJet Firmware became more capable of meeting customers’ demands.

Einstein simple quote

Agile Principle Ten

Simplicity–the art of maximizing the amount of work not done–is essential.

As the quote attributed to Einstein goes, “Everything should be made as simple as possible, but not simpler.” The technology landscape is becoming ever more complex. The possibilities are endless and so are the temptations to create solutions that are unwieldy and untenable long term. For every shiny new technology that comes along promising to make your product better, faster, smarter, etc. there is a potential hidden tax in the form of additional complexity. The challenge is just as the principle states: maximize the amount of work not done. Reaching the proper balance of simplicity and technical excellence is an ongoing pursuit.

Agile Principle Eleven

The best architectures, requirements, and designs emerge from self-organizing teams.

There are a number of frameworks and philosophies catching on in popularity around scaling Agile as we start into 2017. Scaled Agile Framework (SAFe) and Large Scale Scrum (LeSS) are two of the most common frameworks organizations turn to when they want to implement Agile enterprise wide. These frameworks try to address some of the perceived gaps in Agile implementations like Scrum, XP, and even more Lean inspired practices like Kanban or Scrumban. These frameworks for scaling Agile aren’t inherently good or bad, but there is a risk that they override principle eleven by implementing such a rigid structure that self-organizing teams are a near impossibility. The question remains whether this principle is true or organizations are finding a more well defined structure brings about the best architectures, requirements, and designs.

Thomas Edison fail quote

Agile Principle Twelve

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

The Lean Startup movement has popularized the slogan and concept of “fail fast.” The idea is that you build and test in smaller increments so that you can fail faster, thus learning lessons faster as well. Much like Thomas Edison’s famous quote implies, “I have not failed. I’ve just found 10,000 ways that won’t work.” This principle of reflecting at regular intervals coincides perfectly with a culture of failing fast. Some organizations will mistake a fail fast approach as one where failure happens early and often but little to no reflection is required. While this may seem obvious, failing early and often with little to no reflection only leads to chasing the same problems without applying lessons learned.

Conclusion

Even though Agile is no longer new and a hot trend, the principles still hold up today. The tactics for how to apply the principles has changed as technology and business have demanded, but the underlying principles remain the same.

Everyone is doing Agile and Lean

Agile and Lean are old news. Everyone uses and abuses the lexicons. Have a short daily meeting? Call it a daily Scrum. Trying to deliver something in a relatively short period of time? Call it a Sprint or iteration. Have a board with post-it notes in swim lanes? Kanban at your service. Writing some tests? Call it TDD. Attempt to improve a process? Continuous improvement! Use a CI server to run a job here or there? Tell the world you’re doing continuous integration. Code on production? Continuous deployment! Meanwhile, people who list experience with Agile and Lean on their resumes more often than not talk about how painful and all around chaotic it all was. The underlying reason for this bad aftertaste is most often due to the adoption of practices without an understanding of the principles behind them.

The temptation is to read an article, watch a short video, attend a conference session and latch onto a particular Agile or Lean practice without the fuller context. This is especially popular in tech where many (most?) of us have a natural tendency to chase after shiny new objects. Instead of a collection of tools that serve their purpose within a greater context, we latch onto the hammer and start pounding everything in sight. A team struggling on a project decides to try a daily standup because they like that part of Scrum. They don’t realize the nuances behind a daily Scrum. They don’t grasp the commitment demanded by Scrum as a whole, and how the daily Scrum helps enforce that commitment. A standup is easy; building teams dedicated to consistently delivering something tangible in a short period of time is not. Every ceremony within Scrum is there because the principles drive it. Adopt one ceremony out of context and the result is less than satisfying – far short of transformative. Ditto for Lean. The practices are easy to grasp and implement poorly without knowing the “why” behind them.

Wrestling with and forming an understanding of the principles behind Agile/Lean requires perseverance. There are no shortcuts. Trial and error is expected, but not without wrestling with the reason why we’re trying to implement a practice in the first place. Racing from one good idea to the next requires little discipline. Little is learned when a practice is implemented without a grasp of the underlying principles. The failed practice is tossed out and a new one takes its place, awaiting a similar fate. The only way out of this rat race is learning why a particular framework, practice, methodology is the way it is and then identifying and carefully evaluating the problems we’re trying to solve and how the two align (or don’t.) There are no shortcuts. No silver bullets. No buzzwords to save the day.

Bitter Scrum: A Task Board Gone Wrong

I remember reading Bruce Tate’s books on Java and EJB, which were all about anti-patterns, years ago and enjoying them. It was refreshing to read about how NOT to apply certain technologies. While there were plenty of books out there on how to do great things with Java and EJB (stop laughing), many of us using those technologies also found some not so great things we could do with them.

In much the same vain of Bruce Tate’s books, I give you a Scrum anti-pattern. Most Scrum teams will use a daily task board, either real or virtual. The task board contains a Sprint’s user stories and the associated user story tasks in the form of cards. It’s normal to see a few columns across the board along the lines of, “To Do”, “In Progress”, “To Verify”, “Done”, etc. The idea is for a team member to put his name on a task card and then move the card into the appropriate column. This is done throughout the day and especially at the daily Scrum. Below is an example of a Scrum task board.

Scrum task board

Pretty simple. Below is the task board gone wrong. The difference is subtle and deserves an explanation as to why this is wrong.

Scrum task board gone wrong

Notice the extra column, “Today’s Work”. Having additional columns isn’t an issue, but this particular column presents a problem. The way the team uses this task board is to move tasks to “In Progress” when they’ve started work. But, since the team will sometimes start a task but then need to start on something else, the team decided they needed a column that showed what was in progress currently, thus the “Today’s Work” column. For example, in the daily scrum yesterday, Joe said he’s going to get Task A done. Joe moves this task to the “Today’s Work” column. Today, Joe tells the team in the daily scrum that he needed to start work on Task B for another story to help it keep moving forward, so he moves Task A to the “In Progress” column and makes sure Task B is in “Today’s Work”, as he didn’t finish that task yet. The problem is that we have impediments hiding under the “In Progress” column now. Rather than Joe saying that he was impeded from completing Task A, he moves it to a column (“In Progress”) that makes it seem like all is fine. All might be fine, but how do we know? It would be better to mark Task A as impeded. Joe could then make it clear to the team why he made the decision to not complete Task A in order to start on Task B. Everyone would see that Task A is in progress and it’s impeded (as opposed to simply “in progress”). The Scrum Master can help the team tackle this impediment.

Impediments aren’t inherently bad, but hidden impediments are. The task board gone wrong makes it far too easy to hide impediments while also making it difficult for the team to tackle properly. We all struggle with identifying impediments, so it’s important that we make sure our management tools are setup to help us make impediments visible and hard to miss.

Agile – Culture or Characteristic?

Jeff Patton says agile is a culture. Rob Lally says no it’s not, it’s a characteristic. Both make compelling arguments. Jeff points out that agile is ultimately a culture which promotes certain processes and practices, whereas Rob argues that agile isn’t a culture unto itself but a quality an organization can adopt and make part of its own culture.

Agile has a strong culture. Jeff makes this argument clear with vivid examples of language, legends/stories/myths, values/norms/taboos, beliefs/attitudes, rituals/ceremonies, etc. But, does having a strong culture make agile a culture all unto itself that an organization needs to adopt as its own in order to succeed with agile? I don’t think so and this is where I agree with Rob. Agile is not a culture an organization adopts, rather it is a quality organizations can choose to add. Although, I never thought Jeff was arguing that an organization needed to replace its culture wholesale for that of agile’s, as Rob positions his argument against. I interpreted Jeff’s argument more along the one I was making in my 10 Questions to Think About Before Adopting Agile post, which was an organization’s culture needs to align with that of agile in order to realize success.

Rob makes an interesting observation in regards to selling agile as a culture:

Presenting Agile as a culture is something I’ve seen many times, and it puts more people off. Agile zealots, a club I was a member of a decade ago, try to sell Agile as a culture in a way that reminds me of Mao and his Cultural Revolution; they want to come in to your organisation, declare your culture to be bankrupt and rip it out, replacing it with an idealised regime of their own.

I don’t think there is any escaping the scary part of agile. Strong cultures are often scary to those looking from the outside in, whether those cultures belong to agile, lean, open source, religious groups, political groups, social clubs, etc. Those of us advocating agile need to be sensitive to this fact, but there is no escaping it as Rob seems to imply.

In the end, I think the most important takeaway in both Jeff and Rob’s posts is what they agree agile is not – a process or a set of processes. Those that see agile in this way and attempt to adopt it as such are almost certain to fail.

Review The Tests, Then The Code

magnifying-glass

Last week I was talking with one of the developers at work and he was telling me about improvements his team was making in regards to (informal/desk check) code reviews. I told him that was great and then followed that up with a recommendation on how to improve even more.  Next time there is a code review, start with the tests. This will do two things: 1) Stress the importance of having tests 2) Make the review go quicker, as the tests will either be there and make the intent of the code clear or they won’t be there and the review is postponed until tests are in place.

I know I’m not the first to make this suggestion, but I felt it was worth repeating. Code reviews do have value, even when you pair program. At least, I think they do. Pair programming provides two sets of eyes on the code at the time of creation, but it’s surprising what someone who hasn’t seen the code before will find during a review.

Oh, and if reviewing the tests during a code review doesn’t make the intent of the code any clearer, then I suggest the team investigate behavior driven development (BDD). I’m becoming quite partial to the Cucumber framework for BDD, as I like it’s emphasis on user stories with acceptance tests/examples written in plain text and backed by executable steps.

The Customers Disappear Right Before Our Eyes

Tonight I was foolish enough to think my family and I could waltz into a restaurant on Valentine’s and get a table without much trouble. We were trying a restaurant we hadn’t been to before and I realized as soon as we pulled into the parking lot this probably wasn’t the best night to experiment. We went inside anyway to see how long the wait was. Much to my surprise, the hostess told us it was only about a 15-20 minute wait. I looked around the restaurant and, while it was full, there wasn’t a large number of people waiting on tables. We got on the waiting list and then proceeded to wait.

What I saw during the wait was kind of surprising. I noticed that the staff were diligently doing their jobs, quickly moving from one spot to another. I had to be careful not to step too far away from the waiting area or I was sure to bump into one of the busy bee workers. And while the staff was incredibly focused on the operations of the restaurant, I couldn’t help but notice they were almost oblivious to their customers, whether those customers be waiting for a table, eating their meal, or somewhere in between. I looked around the restaurant of about 40 tables and noticed that at any given moment there were numerous people looking to get the attention of their waitress. Customers coming in through the door were rarely greeted in a timely manner. Those of us waiting for a table were ignored completely, even as our original wait time came and went.

It dawned on me that this situation is not unlike what happens with some software development projects. We get in the groove of producing the software and never take time to make sure we’re satisfying the customer. Yes, those of us practicing agile have the advantage of delivering in short iterations which, at worst, won’t allow a project to go too long before the customer is back in the mix. But, even on agile projects, I’ve seen teams go through an entire iteration without giving much thought to the customer’s needs beyond the initial planning meeting. We think we understand exactly what the customer wants, can’t or simply don’t get continuous feedback from the customer during the iteration, and we develop the functionality. We become like the restaurant’s staff, who are so busy running the restaurant that they forget about the very people who really keep the restaurant running, the customers. Sure, the orders are taken, the food is getting out to people, drinks are refilled, new people are put on the waiting list, etc., but the customers aren’t satisfied, let alone happy. The software gets designed, written, documented, tested, etc. but the customers aren’t satisfied, let alone happy. Sound familiar?

Tonight was a good reminder that technical and operational excellence is critical to delivering a good customer experience, but if we lose sight of the customer in that process then we will fail miserably. We need to be diligent about keeping constant contact with the customer and focusing on the value we’re delivering. We don’t want our customers to walk away from us like my family and others did on the restaurant we attempted to eat dinner at tonight.

One Smart Cucumber

I was messing around with some Ruby stuff tonight and was reading up on the Cucumber project. Cucumber is a behavior driven development (BDD) testing tool.

Anyone who talks to me about user stories knows I’m kind of a stickler on the value statement.  I think I’ve found a kindred soul in Aslak Hellesoy, the creator of Cucumber. The following comes from the Cucumber documentation.

You should discuss the “In order to” part of the feature and pop the why stack max 5 times (ask why recursively) until you end up with one of the following business values:

  • Protect revenue
  • Increase revenue
  • Manage cost

If you’re about to implement a feature that doesn’t support one of those values, chances are you’re about to implement a non-valuable feature. Consider tossing it altogether or pushing it down in your backlog. Focus on implementing the MMFs (Minimum Marketable Features) that will yield the most value.

Here is an example taken from an IRC chat session in #cucumber:

I was impressed to find that section in the documentation. Not only do the docs detail basic usage but they go into the deeper discussion of how to apply agile principles using Cucumber. The balancing act of teaching principles and practices at the same time is no small feat. To find that in software documentation is pretty amazing.

P.S. One of my worst titles ever, I know. I think I was subconsciously inspired by the Hallmark Movie my wife had on a couple nights ago. I now realize I missed my calling as a greeting card writer.