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+.
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.
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.
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”.
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.
Be present (no phones, no “side chats/conversations”, no browsing, etc.)
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.
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!
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?
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.
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.
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.
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.
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.
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.
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.
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.
Pretty simple. Below is the task board gone wrong. The difference is subtle and deserves an explanation as to why this is 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.
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.
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.
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.
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:
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:
[5:08pm]Luis_Byclosure:I'm having problems applying the "5 Why" rule, to the feature
"login" (imagine an application like youtube)
[5:08pm] Luis_Byclosure: how do you explain the business value of the feature "login"?
[5:09pm] Luis_Byclosure: In order to be recognized among other people, I want to login
in the application (?)
[5:09pm] Luis_Byclosure: why do I want to be recognized among other people?
[5:11pm] aslakhellesoy: Why do people have to log in?
[5:12pm] Luis_Byclosure: I dunno... why?
[5:12pm] aslakhellesoy: I'masking you
[5:13pm]aslakhellesoy:Why have you decided login isneeded?
[5:14pm]aslakhellesoy:Why doyou have toidentify users?
[5:14pm]Luis_Byclosure:maybe because people like toknow who is
[5:15pm]aslakhellesoy:Why would anyone want toknow who's publishing what?
[5:17pm] Luis_Byclosure: because if people feel that that content belongs
to someone, then the content is trustworthy
[5:17pm] aslakhellesoy: Why does content have to appear trustworthy?
[5:20pm] Luis_Byclosure: Trustworthy makes people interested in the content and
consequently in the website
[5:20pm] Luis_Byclosure: Why do I want to get people interested in the website?
[5:20pm] aslakhellesoy: :-)
[5:21pm] aslakhellesoy: Are you selling something there? Or is it just for fun?
[5:21pm] Luis_Byclosure: Because more traffic means more money in ads
[5:21pm] aslakhellesoy: There you go!
[5:22pm] Luis_Byclosure: Why do I want to get more money in ads? Because I want to increase
[5:22pm] Luis_Byclosure: And this is the end, right?
[5:23pm] aslakhellesoy: In order to drive more people to the website and earn more admoney,
authors should have to login,
so that the content can be displayed with the author and appear
[5:23pm] aslakhellesoy: Does that make any sense?
[5:25pm] Luis_Byclosure: Yes, I think so
[5:26pm] aslakhellesoy: It'seasier when you have someone clueless(like me)toask the
stupid why questions
[5:26pm]aslakhellesoy:NowIknow why you want login
[5:26pm]Luis_Byclosure:but it isdifficult tofind the reason foreverything
[5:26pm]aslakhellesoy:AndifIwas the customerIam inbetter shape toprioritise this
feature among others
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.
Agile. Everyone is doing it, so should you, right? Not so fast. Even though it’s being sold as a silver bullet by various vendors and consultants, agile is far from easy. In fact, I’d argue that adopting agile is harder than moving to a process heavy software development methodology. At least with the process heavy approach you have the how-to guide. Agile is as much about attitude as it is about anything else. And a company’s attitude is found in its culture. Companies with cultures that clash with agile are not likely to succeed in adopting agile.
The following is a list of questions I think anyone considering the move to agile, whether company wide or at a smaller scale, should ask before moving forward.
Is your company policy driven?
If employees feel inundated by policies, watch out. There is nothing wrong with policies, but a company driven by policies is likely to be at odds with agile values and principles that support people interacting with one another over contracts, documentation, and processes. A company culture overrun by policies struggles to trust its employees to make good decisions without heavy handed tactics.
Does your company encourage identifying and eliminating its stupid practices, policies, and processes?
A company culture that encourages, at all levels, the elimination of the stupid things the company does will have no problem latching onto agile’s principles concerning change. Don’t have a culture like that? Good luck with accepting and embracing change in a manner agile demands.
Is the contract king at your company?
Contracts come in all shapes and sizes. Some contracts are legally binding documents between two parties, like a service provider and its customers. Other contracts are less obvious but more prevalent, like change request forms and requirements docs. A CYA approach by employees is often a result of a “contract is king” company culture. Welcoming changing requirements and customer collaboration are agile values and principles that are next to impossible for a “contract is king” company to adopt.
Is “on time and on budget” your company’s best measure of project success?
Agile promotes continuously delivering working software that is valuable to the customer. When delivering on time and on budget is the key measurement to a project’s success, it misses the most important point: value. And this all gets back to our previous question of contracts. Companies that value “on time and on budget” the most as a measure of project success are often the same ones that depend on the contract to determine value, not whether the project truly does deliver something the customer wants or needs. This isn’t to say that agile cares little about time or budget, quite the contrary. Agile focuses on delivering value early and often.
Would a fair description of your company’s structure be one of tribes at war with one another?
A great book to read to get an understanding of what I’m talking about here is Great Boss Dead Boss by Ray Immelman. Examples of warring tribes include production versus sales, engineers versus marketers, accounting versus purchasing, etc. Most of us remember the high school cafeteria and the cliques that form. Most of us laugh at how absurd the cliques got, yet too many of us grow up and create even more absurd cliques in the business world. Agile demands constant communication between people and focusing on the customer. You cannot succeed at either of these if your company is made up of factions of tribes. A company needs to be one tribe striving for a common goal.
Are simple solutions ignored within your company?
Simple is hard and yet agile calls for simplicity. Company cultures that struggle with promoting simple solutions are often the same ones that “try agile” for a bit and abandon it because “agile doesn’t scale”. Also, companies that are in love with solving huge problems with complex solutions often struggle with simplicity. Simple is, well, too simple for these companies.
Does your company advocate and live by the “No Asshole Rule” (in principle, if not by name)?
My apologies if the language offends. I find the behavior and acceptance of such individuals within an organization more offensive. Companies that do not adopt this rule will struggle mightily with agile. Individuals who are grownup bullies in the workplace will make sure that anything like agile, which encourages everyone involved to make good things happen, fails in spectacular fashion.
Is “corporate speak” the primary language spoken at your company?
Communication is key to everything, let alone agile. Being able to reflect and adjust behavior is also key in agile. Speaking in a language that doesn’t say much at all is a serious roadblock to effective communication. Corporate speak is also a sign that a company’s culture may value style over substance. Style can come in the form of fancy documentation but little working software.
Do the people at your company enjoy working there?
Don’t show me the survey done by such and such publication. Those are nice awards to put in the job postings but the real deal is found amongst the people on a day-to-day basis. The vibe of the workplace is hard to miss. Motivated people who feel empowered to get the job done are critical in successfully adopting agile. A place where the people don’t enjoy working for the company doesn’t fit this bill.
Do customers enjoy working with your company?
Customers who go out of their way to say nice things about you because of how much they enjoy your company and its products/services trust your company and are going to want to make good things happen together. Agile is all about working closely with the customer. If customers don’t enjoy working with your company now, there is no magic agile pixie dust to make them enjoy working with your company when it adopts agile.
Some might argue that adoption of agile is an answer to these questions. That may be true, but I have my doubts. Company culture is what needs to change in most cases. Changing company culture in a positive way is difficult. The temptation for many of those considering the adoption of agile is to think of it as just another methodology, process or set of practices that can be adopted. Those taking this path are almost certain to fail. With that failure will come much finger pointing. Agile didn’t scale. Agile wasn’t disciplined enough. Agile is missing X, Y, and Z. Agile simply didn’t work. In reality, agile was never understood and never a good fit from the beginning.