The Agile Manifesto was born out of frustration by a group of developers who were fed up with how software was being developed. Software development is a learning experience and no one understands this better than those who are actually writing the code. Waterfall was a misguided concept that seems reasonable on the surface but does not work in reality. Since software development is a learning process it is impossible to think of every single requirement up front and have them signed in blood before starting development. We are all familiar with the limitations of Waterfall.
However, how many of you have seriously debated or discussed the limitations with Agile? It seems to me that Agile is too often viewed as the silver bullet cure to all of our delivery issues.
Management is constantly under fire from the C-suite to improve the quality, timing and costs associated with software development. In response, many organizations are diving into Agile with the belief it will cure all of their ills. Billions of dollars are being spent on Agile consultants and software solutions to manage requirements and project plans according to the Agile principles. All of this is being done with the best of intentions. With all of the certification programs, books, blogs, software and training programs devoted to Agile it seems to me that excessive process and red tape is taking over the concept of being “Agile”. In multiple organizations I have heard comments such as “We can’t change the questions we ask during standups, if we do we are not Agile!” A number of Agile practitioners have stated to me that if we change the frequency of retrospectives or other Agile ceremonies then we are no longer “Agile”. This concerns me. The goal of software development is not to be Agile. The goal is to deliver high quality software that solves our customer’s business needs. If we achieve this goal we will meet our revenue targets and grow the business. Being “Agile” is a worthless goal. Customers do not care if a company is Agile or not. They care about the quality of the product. Do you think Apple would have more customers if they advertised that they were Agile? This may be coming across as being harsh but I want to emphasize that there is a risk of losing sight of the ultimate goal when implementing Agile. So if I haven’t ticked you off and you are still reading you are probably thinking “Ok, then what do we do about it?” We get stuff done, that’s what we do. I am a proponent of my own software delivery methodology I call “Get Stuff Done” or GSD for short. That’s what we all want to do when we get to work, we want to get stuff done. Companies pay us for how well we Get Stuff Done. Many times our processes and red tape get in the way of this. Think about what you typically complain about at work. I’ll bet that many complaints are about the processes you are being forced to adhere to. Believe me, I’ve had many conversations with colleagues which debate the actual business value of some of the meetings and processes we are forced to follow. So how do we go to work and just Get Stuff Done? Well we’ve all heard about the Ice Bucket Challenge so here is a great first step to take.
I encourage you to take the GSD Challenge! For one sprint or iteration I challenge you to turn off your electronic system for storing requirements and tracking progress. Just say no to using TFS, Jira, Blueprint, Project Server or whatever system you are using. Collocate your team in a conference room. Get yourself some multicolored sticky notes, index cards and Sharpie markers. Write the User Story titles and Acceptance Criteria on the index cards. Prioritize and size each story by writing the priority and story points directly on the card. Tack the cards up on a whiteboard for everyone to see. Have the team write their tasks for each story on the sticky notes. Use a different color for each group (development, test, project management, etc). Paste the sticky notes next to the story. As each task is completed move it across the board to indicate it is complete. If you learn something new and a completed task now requires more work, simply move the sticky note back to in progress. Your team’s progress will be visible to all. Want to know the status of the project? Simply walk into the conference room and take a look. The GSD methodology relies heavily on two skills humans have perfected and used successfully for thousands of years. Bipedal Propulsion Technology (BPT) allows us to use our feet to get up and walk over to colleagues to communicate using Human Voice Technology (HVT). In my opinion BPT combined with HVT is far superior to email as a communication tool. As a bonus BPT is good for you! It gets the heart pumping and progress can be tracked using a FitBit or iWatch!
Collocated teams using GSD don’t have to worry about reserving a conference room for meetings. Calendar conflicts disappear and email communication significantly decreases. Want to call a meeting using GSD? Simply use your Human Voice Technology to call out to the team “At 1:00PM we will be having a Sprint Planning meeting!” It’s as simple as that. Don’t worry; with a bit of practice you will get the hang of using your HVT more often. I understand that email and texting may be seriously eroding your HVT skills but I assure you it’s like riding a bike, it will come back to you. I suggest for maximum success with your GSD challenge you consider providing the following amenities within your collocated room:
- A large conference table with network & power connections for the entire team
- Additional monitors to allow for dual monitor connections
- One or more whiteboards
- A projector and projection screen
A little preparation will go a long way to ensure your GSD challenge is a success. Once the team is collocated and the user stories are tacked up on the board you may follow your preferred Agile ceremonies. Standups may still occur at the same time each morning with the team gathered around the whiteboard to comment on their current tasks and what they plan to work on for the day. Standup is a great time for the team to update the board together by moving sticky notes around as needed. I suggest holding a Retrospective at the end of the GSD challenge to collect feedback from the team on their experience. This should be extremely interesting and provide insight into how the GSD Challenge differs both positively and negatively from your current process.
If you consider attempting the GSD Challenge be prepared for significant pushback from some team members. One of the most common initial complaints about colocation I have heard is “I don’t want to give up my office. I need to think and not be disturbed.” My response is that if your reward for developing software is an office then you have not actually experienced a fun and rewarding environment. Your reward should be developing quality software in a fun environment that makes millions of dollars, not an office. The team should be allowed to develop their own norms concerning how they will work. For example, when someone truly cannot be disturbed they can wear a special hat or have a funny sign draped over their monitor. Have fun with the challenge and begin working and collaborating as a team. I bet you will be surprised at how little you actually miss your office and the electronic systems most of us rely on to track our progress.
The GSD Challenge is not meant to bash Agile or Scrum. It is to get you to actually think about how you are working and whether the principles you are following actually provide value and allow you to Get Stuff Done. The Agile & Scrum principles are guidelines. They are not laws which must never be violated. Listen to your team and adapt to what works for them as opposed to ensuring that someone can call your group Agile or not. Quality software and making money is the goal. We must never lose sight of that. Thanks for reading and I hope you consider going back to work and getting stuff done!
Author: David Shaffer, Business Analysis, Reed Tech
Dave is the Manager of Business Analysis at Reed Tech in Horsham, Pa. where he is focused on mentoring Business Analysts and constantly improving the maturity level of Business Analysis within the software development group. He has established Business Analysis Centers of Excellence within the pharmaceutical, government and manufacturing industries since 2002 and may be reached via his LinkedIn profilehttps://www.linkedin.com/pub/dave-shaffer/0/894/681
Email: [email protected]