Tag archive

user stories

Why I Love the Boards We Use In Agile Software Development

in Agile/Agile Engineering/Product Management/Project Management by

I know this is going to sound weird, but I have an affinity for the boards we use in Agile Software Development (or Agile Project Management). I’m using the generic term board, but you may refer to them as Storyboards, Taskboards, Testing boards, kanban boards, or simply job boards.

If I get into the way-back machine; back to when I first started my career. I was in Valdosta, Georgia working my first job out of college, Trus Joist MacMillan, and I was being walked around the manufacturing facility. I was in awe and deep appreciation for what I was learning. As I went through the customer service area, I noticed a large magnetic board and on it were these color coded cards with lines that represented stages and dates running across the top. I inquisitively asked, “what is that?” They quickly and proudly gave me the run down that these things all represented our customer’s requests for goods (a.k.a. orders). The columns represented stages of the manufacturing cycle and the lanes represented weeks. This board was the central information hub for the plant — the board described everything going on from department-to-department. It gave the all plant team members indicators as to how well are we satisfying our customers, what’s coming up for the next week, and which customer orders were being held up. The other thing I noticed is that as you went throughout the facility, other departments had similar boards that were a reflection of the main board but for the specific customer requests they were working and the boards reflected each departments workflow.

Does this sound familiar?

If it doesn’t, then you are probably not working in an agile world, or living under a rock, or you are using agile by you are missing out on something great. Me and my colleagues talk about metrics a lot – with our customers and internally. Well, in case you didn’t notice, the boards themselves are living breathing metrics. The boards are the team’s communications central as well as a key way to see collectively “how are we doing?”

In fact, the boards often ask just as many questions that they answer. These questions can vary based on your role and whether or not you are an embedded team member using the board or a bystander looking to gain insights from the board. I took on the the challenge of looking at questions asked and answered by the boards and found 40, yes 40 — check them out on this mind map. I’m sure there are more; however, I figured 40 was a good start and stop.

Mindmap of Questions with Boards

Besides all the questions boards ask and answer, I also love boards for their ability to simplify the portrayal of real-time information while being able to have complex information tucked away in the details. Teams can easily innovate and adapt their boards with the use of colors, pictures, lines, layouts, materials, etc.

Finally, I love boards because they actually build the teams. They provide a place to recognize accomplishments, share challenges, and they are the place to stand around and talk about what is happening on the project. If you are using an electronic board, you can still gain these valuable intangibles by keeping the board up-to-date and driving all collaborations on what is happening on the boards. Boards give teams focus, while also given them information that empowers them to make decisions to get things done and meet commitments.

Please share your thoughts on why you like, love, or hate the boards your teams use. Share some examples. If you are not using a board today, why not? Trust me — you will be glad you did.

Checkout this gallery of board examples that I found:

v1storyboard
v1epickanbanboard
Neon Board
Quadrant Board
magnetboard
kanban-full1
IMAG0033_thumb[2]
dsc_0281
bigboard
Agile Task Board

SUCCESS = RESULTS – EXPECTATIONS

in Project Management by

When I talk with folks learning about Agile, I often play the game Presto Manifesto where the room talks about what it means to have a successful project and then break up into groups and based on their experiences come up with a list of critical elements that they’ve noticed on successful projects. This exercise is meant to bring people to the concepts of what makes up the Agile Manifesto.
success
The interesting thing is that in many cases we discover that we’re programmed to believe that failures of projects relate to not knowing everything up front. I almost always hear, “complete, thorough, and approved requirements” as an element of successful projects. This programming aligns well to the formula of success I learned during a short stint at an ERP consultancy firm:

SUCCESS = RESULTS – EXPECTATIONS

This formula leads us to make sure we set clear expectations so that we can meet and hopefully exceed them; thus, leading to success. However, as we know and learn in Agile (and really any process) – thinking the users/customers know everything about a project (a.k.a. need) six-to-nine months before they get their hands on it is simply a fallacy. Sure we can make the customers agree to the expectations ahead of time, but doesn’t that negate the ability to ensure that value and ROI is actually achieved on the project. What generally happens is that the customer/user defines the requirements and agrees to them, then sometime about a month before the project is delivered — they get their hands on some working capabilities and the say, “this doesn’t work like I expected, can you add a screen that does this and we’ll need a report that gets generated daily; if we don’t get these, we really can’t use this.” The response of the team is first, “but you signed the requirements document” or “those are great ideas, we’ll need to do that in the next phase” or “that will need to go through the change control process, we’ll need to escalate this.”

Ultimately, the team is not happy because they don’t get to experience SUCCESS because the RESULTS fall short of EXPECTATIONS. On-top-of-this, the customer is not happy either.

By using an Agile approach, we can improve on our SUCCESS rate through applying these very basic ideas:

  • The customer (a.k.a. the Product Owner) stays engaged with the team delivering throughout the project life-cycle. In fact, they are part of the team. At no point in the process should they disengage; thus, decisions and expectations are set near the time the need is built and subsequently delivered – requirements evolve. And since the customer stays engaged, changes should not be surprises to either the delivery team or the customer.
  • Needs are delivered in small valuable bites. This means that the delivery team and customer work together to understand what is smallest piece of value that should be delivered first and they deliver just that. This approach helps both the customer and delivery team by narrowing focus which results in faster delivery and a focus on getting the high-value need right (with quality). By the way, if the delivery team falls short of expectations for some reason it should not be a surprise to anyone and since we handle just a small bite – we fail small.
  • At regular intervals the delivery team (including the Product Owner) shows off the demonstrable product increment. Preferably what is demonstrated is a complete capability; however, this is not always possible. At a minimum enough is demonstrated so that feedback can be provided and the team can show that they are doing what they said they would. This demonstration provides a checkpoint for measuring success as well as it provides a way that expectations can be continuously molded and refined.
  • Conversations are constant within the delivery team, with the customer, and the stakeholders. Instead of having formal meetings that are dubbed “Status Meetings” — we have ongoing, regular discussions about the EXPECTATIONS. When an engineer has a question, they grab the key team members and product owner and discuss real-time. This results in clear understanding and a lack of hand-off breakdowns (where information is translated as it passes from one person to another).

There are many more things we do with agile delivery methods that ensure our projects are successful (e.g. continuous planning, short release cycles, engineering best-practices, and a ephemeral drive to get better). But if you start with the above ideas, I can assure you that the team and the customers will start getting that feeling of SUCCESS.

What are your thoughts?  How does your team measure success? Another great question, do you define SUCCESS before you start your projects?

Go to Top