Category Archives: Scrum

The Elevator Pitch

Could you clearly and concisely explain to someone what the project you are working on does? Not technically, but from a business perspective? Could you, if asked, explain what the main features are and why your project is a good alternative to the status quo? In other words, can you give a business justification for the project?

If you can, fantastic. You are making good strides in setting your project up for success. If you said no however, you are unfortunately in the vast majority of development teams out there. As developers we tend to separate our teams into the “business units” and the “technical” groups. We figure that we can deal with the tech decisions and they can make the business decisions and everyone will be happy. Unfortunately for us, we forget that every decision we make, impacts the business. We are all on the business side of the project. As developers, we make hundreds of small decisions every day and it is very easy for us to get caught up in the tech, and lose sight of what the real purpose of the project is. In my Why are we here post, I talked about the importance of understanding why we are doing a project and to keep the customer in mind as we do it. The next logical step in that process is to formulate a clear and concise explanation of the “why” so we can both keep ourselves focused, but also to aid us as we engage our neighbors. I call this, “The Elevator Pitch”

Now, this concept is not new. If you stepped onto an elevator with someone and you had to explain something to them before you got to your floor, could you? Some elevators are slower than others, and in my building I could read them a 30 page document by the time I hit the 3rd floor, but you get the basic idea… And besides that, you should be taking the stairs anyway… But I digress…

In order to formulate an elevator pitch you need a few important pieces of information. If you are already working, you should have them. However, if you dont, call together the “A Team” (thats a different blog post) and the Product Owner ( Yet another post) and ask these simple questions.

    Who will be using this product?
    What is the basic thing they are trying to accomplish?
    What is the key benefit of this product?
    What is different between the current state and the new state?

Ok, now that you have all of that, you need to put it together in a clear and concise format. This seems to work well for me.

For [Customer]
Who needs to [Need]
The [Product Name]
Is a [Category]
That will [Key Benefit]
Unlike [Primary Alternative]
The new system will [Differentiator]

So,

For The Accounts Payable Team
Who needs to effectively process invoices
the paytastic 1000
is an online payment system
that will allow AP to process invoices quickly and efficiently.
Unlike the current paper based system
The New System will ensure that invoices are not lost and kept in proper workflow.

Now, with that simple explanation, you can clearly explain to anyone what it is you are trying to do and what the most important things are.

The Why of Scrum — The Standup

A wise man once told me that most developers dont care about the why, they only care about the how. That is especially true around process and agile development. Developers want to know “how” to do scrum, but rarely want to know “why” they do it. The issue with this mindset is that scrum and agile in general are highly adaptable. Scrum is full of independent concepts that can be adapted to your individual circumstances in order to achieve a highly efficient and productive team. However, when you don’t understand why you are doing them, you tend to adapt out the good stuff and miss the whole point of what you are trying to accomplish with Scrum.

Probably the most misunderstood and abused concept in Scrum is the daily stand-up. I have seen many instances where developers go through the motions of the stand-up, they even ask and answer all the right questions, but they are doing it for all the wrong reasons. Ultimately, the purpose of the stand-up is for the team to know what the team is doing. The purpose is not for the scrum master, project manager, or team lead to know what the team is doing. When you pull a team together for a daily stand-up, that is their opportunity to listen to what is going on, understand where the pieces they are waiting on are at, know what struggles their teammates are going through, and be able to voice what your own struggles are in an attempt to get assistance or understanding from the team.

At its core, the stand-up is about forming a group of people that are all in this together. In other words, a team… If you are checking your email while your peer is giving a status report to the team lead, you are not part of a team. You are an individual who may or may not contribute to the overall success of the group. If you are “tweeting” instead of listening to the struggles of your peers, you may be doomed to repeat their pitfalls.

So, tomorrow in your stand-up, put your phone down and make eye contact with every person that gives their update. Ask yourself, “How does that impact me?” or “Have I struggled with that before?” Have your first response be, how can I help these people out to contribute to the overall success of the group. That ultimately is what a team does.