Jacqueline: Hello. This is Jacqueline-Sanders Blackman here with a full-length episode of our STEM Information Podcast. This series is also associated with our #AskTheAgileAnalyst. Some of you may have heard of my previous podcast where I talked about how our previous #AskTheAnalyst series is going to break up into two series. Kupe Kupersmith will still be doing some episodes with us to talk about everything from decision-making to critical thinking as well as improv. I will be continuing a series that’s related to analysis in software development and design specifically in the area of agile.
Many of you may know: by day, I do business analysis and have done “business analysis for the last 30 years, which is where my passion for technology and computing and software design come from and manifest themselves. That extended to my interest in advocating and promoting STEM across the board.” This episode, I want to talk about, whether you’re in software design or not, the revolution that’s happening in industries and businesses. “The topic of agile is a hot topic, and it’s not just a topic. It’s a framework. It’s a mindset. It’s a culture change. It’s a paradigm shift. All of the above.” I’ll start at the beginning then dive deep into an area for those who have already attempted, started or are in the middle of their transformation. I have some key pointers for you.
What Led to Agile?
Let me just set up the topic for those who might be new to it. Agile, when I talked about it being a paradigm shift, we’ve gone through a period in software design where we try to come up with the most structured development approach and development methodology so that everything was pre-designed and locked down well before you started creating the software. In theory, that makes all the sense in the world. You don’t start building a car until you have some type of blueprint all laid out. But software development quickly proved to be a little bit different and a little bit of a different challenge. Some things you often hear me say is that software development is not cookie-cutter. For those of us who are in software development, that’s a good thing. We thrive on the ever-changing, the new developments, exploring the unknown, trying and problem-solving.
With that said, it doesn’t fit nicely into an extremely structured methodology. You can’t know all of the specifics up front before you start building. Some things you just discover as you go along. Well, that resulted in many different variations of methodologies, but ultimately this 30-year quest for a methodology that fits best with agile has now peaked everybody’s interest. All the chatter is about agile. “Agile is all about flexibility and being able to pivot and to learn as you go. Some people call it ‘learning fast,’ and other people call it, ‘failing fast.’” But that’s ok, because that’s also very much in line with how entrepreneurs, innovators and inventors come across their biggest, brightest and best ideas, which is by failing fast. With that said, I don’t even want to call agile a methodology because it’s just that flexible.
“The baseline for agile is what’s called the Agile Manifesto.” If you’re listening to me and you’re near your computer, type in Agile Manifesto and you’ll see the framework for agile. That’s Agile 101. What I wanted to really dive into is about those organizations that have bought in and understand, in theory, what agile is and are now trying to transform whole organizations into agile. Thus, my title: Agile can be Fragile. The reason why I say that is because it’s one thing to read a book that says, “Hey, here’s a manifesto. Follow this.” You get ceremonies that fall under the umbrella of scrum, or you use a kanban board to track information. You buy a tool that was made for agile. It even goes a step further. You scale it and you use one of the models for scaling, such as SAFe (Scaled Agile Framework).
If you do these things, then you are doing agile and therefore should see all of the returns and benefits of agile like the flexibility and being able to build things fast. I’m saying all of this tongue-and-cheek, because it couldn’t be further from the truth. If you just read a book—and I know some companies that do less than that; they just have people watch a video on YouTube then say, “Let’s do agile.” The truth of the matter is that it’s not a methodology. It’s not do step A, B and C and therefore you are doing agile or you’re doing agile right. Again, it’s not that simple. Furthermore, if you’re doing it within the boundaries of a company, organization or business that already has a legacy approach, legacy training and even a legacy mindset. An organization that has been doing waterfall for 10, 20, 30 years then suddenly you say, “We’re going to go agile. We’re going to send some people to training, they’re going to come back, they’re going to have certificates and now we’re going to do agile.”
It doesn’t work that easily. As a matter-of-fact, that can complicate things. What happens is when people get exposure to agile and their first experience is a bad experience, they become completely gun-shy and look at agile as a punishment or as a way to trick them into messing up. They fear for their jobs. They fear for their promotions. People have been on track with performing well in the waterfall world even if it means late hours, long days overtime, stress and even a combative environment among team members or other teams. Yet, people have been successful and have received accolades, promotions and salary increases. “They’d rather go with the known than trying something unknown that could risk everything as they know it.” They’ve gotten comfortable even with the dysfunctional environment and framework that they work in. So, put all that together with a bad agile experience and you’re going to have people that are reluctant to try to trust that agile is going to work. Suddenly, you have a very fragile environment.
And I say this because I’ve created a bootcamp with B2TTraining, which a lot of you know me through. I’ve created and have been a part of transforming a curriculum that includes an agile analysis bootcamp and a Scaled Agile Framework bootcamp. Both of those offerings are available through B2T, and as a result of teaching this in over a dozen different places just this year, I see and hear the same things over and over. Trust me: I feel your pain, I empathize and I understand. A lot of it isn’t just a training issue. There’s a mindset, and there’s a disconnect. Agile can be used as a weapon, it can be used against people, it can be used to micromanage or isolate and it can be used for finger-pointing.
I point all these things out because these are some of the same complaints we had with waterfall. Why are we going to agile and still having the same complaints? I would defend and can prove that it’s not agile, but it’s just the same bad habits being carried over. If you go to class and you return with the same bad habits, then you’re still going to see the same problems and issues. If you have an environment of finger-pointing or people who want to be a superhero and put being a hero above being a team member and being continually rewarded and recognized for that, then that’s the behavior you’re going to see. It takes a big step back. “It takes going slower in order to get faster.” “If the long-term gain is going not just faster but building the right things and getting to the customer sooner, that’s something that I really try to stress.”
Agile as a Shift in Thinking and Doing
People change their vocabulary. Never do I like to hear people say, “Agile helps you go faster.” “It helps you get the right things built and get the right things the first time.” It doesn’t shave time off of the build process or the design process. It doesn’t even encourage you to shortcut testing. You might do it all collaboratively, but “I still encourage you to take the time to do a quality job the first time,” whatever that takes. It’s not about cutting corners. With that said, I truly am a witness to agile being successful in many environments, and probably in an environment just like the one you work in. The biggest difference is just the whole organization collectively taking a deep breath, exhaling and taking just a small step back in order to move forward.
“The main thing that needs to be addressed above all is people’s mindset and the culture.” A lot of people don’t like to hear this one. I’m coaching them when I say this: by and large, when agile doesn’t work, it’s because you have a dysfunctional relationship among and between either IT, the business, its stakeholder or the leadership that is making strategy. “What it takes is not just one of these three changing but everyone giving up something, changing their mindset and leaning into some discomfort.” If an organization is transforming to agile and there is no discomfort, you’re definitely doing something wrong. That means there’s going to be some discomfort with upper management, middle management, project management, developers, testers, business analysts, product owners, SME’s and customers. “This is a transformation top to bottom. This is a culture change.”
I don’t just want to keep everything anecdotal and talk about how agile works or doesn’t work. What I would like to do is walk through some of the very practical things that I see get overlooked when we talk about agile and agile transformation and just make a list. I have before me 13 steps. This isn’t the unlucky number 13; this is lucky 13. 13 steps and pointers around agile value management and analysis. I want to take you from the beginning of the projects all the way to the end and give you some of my key pointers along the way from an analysis and value management perspective.
One of the pain points people often find in agile is that even though you’re going through all the ceremonies and you’re moving at a very fast pace, without some of the foundations we identify in business analysis, you’ll still end up building the wrong things really fast. Nothing frustrates a product owner more than receiving the wrong solution, especially after all the extra pain, effort and engagement of agile but still getting random pieces instead of getting the big, high-dollar, high-valued business items that help lessen their pain or help them reach and attain the opportunity they’re seeking. People usually call us at B2T about problems with their user stories. That terminology has replaced what we used to always hear, which is, “There are missing requirements.” It’s now, “We’re having problems with the user stories.” That’s because everybody likes to start and point to the smallest piece when really, it’s a by-product of a whole series of events.
That’s what I hope this roadmap that I’m going to talk through will help. One of the things is that we have to map what we did in traditional waterfall and make sure we keep and maintain those pieces that had purpose and value in the software development process. “A “true” agile project means there’s a small team of 8-10 people focused on a type of feature or epic that has been prioritized and will be funded, there has been a product owner, a tester and a business analysis assigned, they communicate daily, they have daily standups, they have planning sessions and they have a standard, agreed upon cadence which they deliver on a group of stories called a sprint or iteration.”
Before we kick all of that off and start finding and planning for the individual sprints, which I’ll call development sprints, because this is the point where the work actually gets done; this is when the tester, the developer, the lead designer, the business analyst and the product owner all sit around and design, build and test the component story by story. The results of those stories are the building blocks to the overall solution. Before you start, you have to have some type of context. That hasn’t changed. One of the first things is I have teams established called information radiators. If you’re not familiar with information radiators, on B2T’s Trainings’ website we have a vocabulary list for agile; it’s the agile alphabet. Feel free to visit it, and we also have a comprehensive business analyst glossary. I’m not going to explain each one of these terms, but I’m going to encourage you to visit our website to learn more about them.
Thirteen Lucky Steps and Pointers to Agile Success
1. So, you “identify your information radiators”. That would be your constraints, your dependencies, your risks, your decisions and your assumptions. Information radiators literally should be visible, working collections of bullet points that are posted usually on one of the white flip charts. I have a wall wallpapered, whether it’s in my own area or it’s when we turn a conference room into a war room, which means it’s dedicated to our project. But, they should be visible. Any time a constraint, dependency, risk, decision or assumption is discussed, you put it up on the information radiator. Therefore, it always stays visible to the whole team.
Next one is information radiator for out-of-scope items, because yes: in agile, there are out-of-scope items. When you are setting up iteration zero, which is going to be the next thing we talk about, you set up the scope of the project. Just because it’s agile does not mean it’s a blank check and that suddenly, the company has discarded all budgets and says, “Anything goes. Build whatever you want for as long as you want.” That’s not the case. Agile wouldn’t be around long if it didn’t have a way to accommodate dates, budgets and deadlines.
2. The next thing is setting up your “kanban board, or what we call your ‘discovery’ board”. It’s the raw stories during the brainstorming process of iteration zero. Create a space to discover your raw stories. I’m specifically saying raw because of the life cycle of stories. They start off as raw, then they become rough, then refined, and ultimately ready. The raw stories are what we call the placeholders for planning purposes. Then, the kickoff for iteration zero, which is the planning iteration. Once we start giving whole numbers to the iteration, then we are in the development cycle. The iteration zero is where you do all of your scoping and initiation in kickoff. You establish what we know as the features.
With any big project in scaled agile, you have an initiative that comes out of the strategic planning and pillars at the portfolio level. That’s the top level in the hierarchy. The middle layer is known as the program level. This is where planning and coordination takes place. Epics, or those initiatives at the portfolio level, are broken up into the features. “Those features ultimately become user stories at the team level. Every user story should be mapped to a feature, and multiple features make up and address an epic”. In agile, since we keep everything lightweight, even the business case should be very lightweight. There are specific templates that are no more than two pages, or one page front and back. In that is also the epic value statement.
3. From there, we’re ready to kick off iteration zero. Some of the things that I recommend for iteration zero is just baselining with a very lightweight problem statement which we refer to as the context level data flow diagram for identifying your inputs and outputs and high level processing. When it comes to software development, everything we do is about transforming and processing data, so “understanding the data flow and the high level processes are all part of your iteration zero and system thinking”.
4. The next big category is establishing your goals and your smart objectives: “clearly understanding what you want accomplished and how you’re going to measure success”. Your smart objectives will be how you’re going to make decisions about what’s in scope and out of scope. If it does not align with your smart objectives, then it’s out of scope.
5. The 5th category on the roadmap is populating your backlog: “identifying the features and the benefits for that objective”. There’s also something known as minimal buyable feature. Even challenging whether you need all of the features and if you need all of the stories within the features. Keeping the feature list slim from the onset. Furthermore, you then populate the backlog based on the stories that come and reconcile to each of your features. Starting at the top, an initiative can have many features, and features will then breakdown into stories. The stories represent the functional requirements for your initiative, but there are other work items that also get populated in your backlog, which can include your technical stories, your spikes and your nonfunctional stories like security and performance. “Don’t forget your documentation stories”.
Now, if you have a big question mark when I say ‘documentation,’ that’s for another episode where I’ll talk about documentation work items within agile. People think because agile promotes lean documentation, agile is promoting that for the purposes of the software development process. Agile does not and cannot tell an organization not to create customer documentation, system documentation or support, help or training documentation. Those are other work items that go with the deployment of a system. We’ll just put a bookmark there and come back to that topic for another day.
6. As we move through, we’ve now made our way through iteration zero. We’ve started populating our functional user stories as well as other work items. Now, looking at the overall backlog, we have a couple of options. First of all, doing an estimate of the full backlog: taking each one of the stories and using relative sizing techniques to ultimately size everything in your backlog to a rough magnitude. Add up all of those stories based on all of those numbers, then take that and document that as the total backlog. Then, go back through and find your minimal buyable product. Sometimes this is where dates and deadlines come in.
7. ”If you have a deadline, then what you will want to do is calculate the number of sprints that can fit in that deadline”, and give yourself enough room for any packaging, finalizing, hardening and any other type of formalities that are needed. Make sure that you give yourself enough time, which might mean you can’t take and divide the number of weeks by two weeks and plan to do stories all the way up to the last week. The last two or so sprints might be dedicated to packaging and to finalizing the administrative pieces. Once you have your minimal buyable products, one of the ways to approach your minimal buyable product is by giving value points to each of your stories and even numbering your value points 1-30 to say, “What are the items that bring the most value?” Let that help you determine your MBP. That is your iteration zero.
8. Once you establish your MBP, now you have your priorities. “From your priorities, what you want to do is start on your sprint planning”. The first time doing your sprint planning, you always want to have three sprints worth of backlog items. Have those stories refined and ready. Then, at your planning meeting, determine your velocity, which in the beginning, might be an estimation. Based on that velocity, pick the stories you can put in that sprint. From there, make sure the team is in agreement with those items and that they feel confident once they commit to the items in the sprint, they will be able to complete them. “At that point, let the sprint begin”.
9. We begin what we call the scrum cadence starting with the planning, creating your visual kanban, doing the work daily, having your daily standups to touch base, and then at the end of your sprint which is four weeks max but usually two weeks, you’re doing some type of sprint review and demo. Keep in mind that the end of the two weeks is not the only time you can to do a demo. “You can do it at any point you have something where the product owner can give you feedback and let you know if you’re on the right track”, if we’re going in the right direction and if it addresses the acceptance criteria for the story. That’s why when we talk about user stories, we refer to the three C’s: the card, the conversation, the confirmation.
10. At the end of each sprint, there’s a team retrospect. “This is to check on the health of the team. One of the things that’s so important to quality software is an engaged, empowered and motivated team”. If they in any way feel demoralized or the energy is low, time and time again we’ve seen it reflect in the software. Again, your retrospect should be an opportunity to see how the team feels about their role individually, their collaboration as a team, their communication as a team and if they feel empowered.
11. From the retrospect and the demo, lastly, whether we’re looking at the product or the team, there’s one key question: “Are we going in the right direction?” Everyone on the team should have a voice and answer that question. Some teams do it with the thumbs up, thumbs down, but one way or the other, everybody should be able to weigh in on that question. If a product owner says, “No. This isn’t what I expected. This isn’t what’s going to work for us,” then there should only be one answer, “Great.” Great because we want to find out sooner rather than later. If some things are not right after two weeks, it’s not going to get right after two months or two years. I’ve seen people in a waterfall project invest years into a product but going in the wrong direction and never asking for course correction or feedback. “They deliver the final product just to find out they’ve built the whole thing off of a wrong premise”.
12. So, value management is about asking the question early and often: Are we going in the right direction? Another important part about value management is asking the question: Are we done?” What you don’t want to do is to keep building without asking on regular cadence, “Are we done? Have we addressed the problem? Have we taken advantage of that opportunity?” Because there’s always something else we need to get to in the portfolio backlog. The purpose of completing your team stories and features is to get to the next big thing. Companies want to leverage agile so that the business can be agile. It has gone way past just being IT agility. It’s about business agility.
13. Lastly, there’s a very important line that I’d like to remind people about when it comes to value management in agile. It starts out by referring to simplicity, which is defined as “the art of maximizing the amount of work not done.” This is essential. “Basically in agile, you want to keep it simple”. You want to do the minimum, and you want to maximize leaving work undone. That means when the product owner says, “Yes. We’re done. This addresses my problem,” then whatever is left in the backlog can be archived. That’s a good thing. We want to do the minimum to get the maximum benefit. We haven’t been asking that question on a regular basis.
I’ve just given you the 13-step roadmap. There’s a visual that goes along with this, and if you’re interested in the visual, send me an email at email@example.com. We’ll be happy to send it to you. If you’re interested in our bootcamp and want us to bring our bootcamp to your company or if you would like to attend one of our public bootcamps, please, again, send me an email at firstname.lastname@example.org. That’s all for today. Thank you for listening. I hope you enjoyed our full-length episode. To my agilists out there: don’t be discouraged. Agile doesn’t have to be fragile. Bye for now!