The Agile Problem Solver
How to Demo Your Backend Software Increment
I’ve talked about some of the situations where you might have be working on software that has no direct end user- or customer-facing behavior. For instance, let’s say that you work at a company that sells a realtime operating system. The majority of the value that your product delivers to customers is via the API (Application Programming Interface). End user applications of various kinds are built on top of your operating system by software developers at other companies. You and your team have begun to use Scrum for development because…well…it’s always a good idea to use Scrum to do software development. Soon you will run into a very common problem for those in your situation.
You might also be at a company that is early in its Agile transformation, and your team might be working on a component of a large system because your organization hasn't yet implemented Feature Teams.
The problem is, what will you do when it comes time to demo your product increment at your sprint reviews? How will you show that your software is doing something that is by definition invisible to users? How will you make your demo dramatic and compelling? How will you keep your audience from falling asleep without doing extensive development?
Here are a few suggestions:
Your audience might not be able to picture the system context of what they are about to see. There’s a great post about this in the Agile Project Manager blog (http://agile-pm.blogspot.com/). The idea is to create some visuals (I think this is a euphemism for slides) that show the audience what is about to be demonstrated. I recently saw this being done at a client of mine and it worked really well. In fact, I had the impression that the business folks who attended this particular sprint review might not have been there at all without the introductory slides to explain to them what they were about to see.
The next place to look is to your automated acceptance tests (you have them, right?). How long do they take to run, and how do you monitor them? There’s nothing wrong with running your acceptance tests during the demo and let the realtime test results provide the show. Many teams have web pages or other reporting mechanisms that show the success or failure of individual tests. Coupled with some graphics, this can demonstrate your software in a reasonably effective and interesting way.
Does your software run in a production environment? If so, then you must have any number of realtime monitors that tell you not only the basic health of the system, but I bet you also have things that show realtime system parameters and usage data. These are another good way to demo your software feature, and if you don’t have these things, you will become addicted to them if you begin to create them. Use them for demos and for realtime monitoring of your apps in production.
There is always a way to show someone what your software is doing. Be creative.
You might also be at a company that is early in its Agile transformation, and your team might be working on a component of a large system because your organization hasn't yet implemented Feature Teams.
The problem is, what will you do when it comes time to demo your product increment at your sprint reviews? How will you show that your software is doing something that is by definition invisible to users? How will you make your demo dramatic and compelling? How will you keep your audience from falling asleep without doing extensive development?
Here are a few suggestions:
Your audience might not be able to picture the system context of what they are about to see. There’s a great post about this in the Agile Project Manager blog (http://agile-pm.blogspot.com/). The idea is to create some visuals (I think this is a euphemism for slides) that show the audience what is about to be demonstrated. I recently saw this being done at a client of mine and it worked really well. In fact, I had the impression that the business folks who attended this particular sprint review might not have been there at all without the introductory slides to explain to them what they were about to see.
The next place to look is to your automated acceptance tests (you have them, right?). How long do they take to run, and how do you monitor them? There’s nothing wrong with running your acceptance tests during the demo and let the realtime test results provide the show. Many teams have web pages or other reporting mechanisms that show the success or failure of individual tests. Coupled with some graphics, this can demonstrate your software in a reasonably effective and interesting way.
Does your software run in a production environment? If so, then you must have any number of realtime monitors that tell you not only the basic health of the system, but I bet you also have things that show realtime system parameters and usage data. These are another good way to demo your software feature, and if you don’t have these things, you will become addicted to them if you begin to create them. Use them for demos and for realtime monitoring of your apps in production.
There is always a way to show someone what your software is doing. Be creative.
I Go Back to College at Rochester Inst. of Technology
Friday, April 17, I spent the day at the Rochester Institute of Technology, and I had a blast. In the morning I held a two hour workshop on the Principles of Scrum. Over lunch I gave a talk titled "Secrets of Scrum Success", and I spent the afternoon talking to a student software engineering group and to various faculty members. It was a terrific day and I want to thank Professor Jim Vallino for making it all possible.
My visit was part of the ViSE - Voices in Software Engineering - program. RIT is interesting in that it has both Computer Science and Software Engineering programs. The SE program focuses a little more on teamwork and practical software engineering issues while the Computer Science program is more about traditional design and programming concerns. So the SE students and faculty are already interested in project management and teamwork. They even have a course in Agile Project Management!
I tried something different with the workshop. It was based around some of the exercises that we do in many Certified Scrum Master courses. Each exercise tries to emphasize and demonstrate one or two scrum concepts in a dramatic and obvious way, and the idea for the workshop was to emphasize a deep and visceral experience of a few basics rather than trying for the more common overview. So we spent a couple of hours exploring self-organization and command-and-control and velocity measurement. As usual, everything took longer than I expected and we didn't get to do everything I wanted, but I think the people that were there took away a good feel for some important underlying principles.
The talk continued that theme by analyzing scrum using the seven principles of Lean software development. At the end, I proposed that the root of why scrum works is contained in these things:
◆ One-piece flow
◆ Self-organizing teams
◆ Tight feedback loops
◆ Transparency
A video of the talk is available here: Secrets of Scrum Success.
After the talk and workshop, I spent an hour with the students of the RIT Society of Software Engineers, which is the group that sponsored my visit. They're a great bunch of students who are very proud of the differences between them and their Computer Science colleagues. They were very interested in Agile, and many of them had tried scrum when they worked on some large class projects. I really liked their passion and curiosity.
So, all in all, it was a great day. I got to talk about scrum to students, professors, and industry professionals. I had pizza and I was presented with an excellent RIT sweatshirt. I really can't think of any way the day could have been better.
My visit was part of the ViSE - Voices in Software Engineering - program. RIT is interesting in that it has both Computer Science and Software Engineering programs. The SE program focuses a little more on teamwork and practical software engineering issues while the Computer Science program is more about traditional design and programming concerns. So the SE students and faculty are already interested in project management and teamwork. They even have a course in Agile Project Management!
I tried something different with the workshop. It was based around some of the exercises that we do in many Certified Scrum Master courses. Each exercise tries to emphasize and demonstrate one or two scrum concepts in a dramatic and obvious way, and the idea for the workshop was to emphasize a deep and visceral experience of a few basics rather than trying for the more common overview. So we spent a couple of hours exploring self-organization and command-and-control and velocity measurement. As usual, everything took longer than I expected and we didn't get to do everything I wanted, but I think the people that were there took away a good feel for some important underlying principles.
The talk continued that theme by analyzing scrum using the seven principles of Lean software development. At the end, I proposed that the root of why scrum works is contained in these things:
◆ One-piece flow
◆ Self-organizing teams
◆ Tight feedback loops
◆ Transparency
A video of the talk is available here: Secrets of Scrum Success.
After the talk and workshop, I spent an hour with the students of the RIT Society of Software Engineers, which is the group that sponsored my visit. They're a great bunch of students who are very proud of the differences between them and their Computer Science colleagues. They were very interested in Agile, and many of them had tried scrum when they worked on some large class projects. I really liked their passion and curiosity.
So, all in all, it was a great day. I got to talk about scrum to students, professors, and industry professionals. I had pizza and I was presented with an excellent RIT sweatshirt. I really can't think of any way the day could have been better.
Making Ends Meet in a Client-Server Architecture
Last time I started talking about back-end software and how to think about it in an Agile way. The problem is deciding when it is 'OK' to treat it as its own complete software system with its own customers and user stories, and when it should only be treated as a component. We try not to assign a team to a component because a component doesn't deliver value to customers, yet sometimes the lines blur. So I thought it might be instructive to talk about the second-simplest kind of back-end software there is. I'm referring to the Server in the ubiquitous Client-Server architecture.
Teams that work on systems with a Client-Server architecture traditionally divide up into a Front End team and a Back End team. Seems pretty logical. The developers that consider themselves front-end people, or GUI people, all get to concentrate on the user experience, while the back-end people aren't burdened by those concerns. They are just the hardcore folks who wrangle the data. Often, they're the ones 'close to the iron'.
What happens when these teams adopt Scrum? In the best of all possible worlds, somebody on one of the teams notices that the Product Backlog of one or both teams doesn't really contain items that deliver customer value. The Back-end team has items like "search for overdrawn accounts" or "archive audit logs". The Front-End team has Product Backlog Items (PBIs) like "As a user, I can see my account balances" and "As a user, I can cancel my account if it has zero balance." The teams are assigned to components and it is impossible for either team to work on a single Product Backlog item that cuts through both levels of the architecture (client and server) in order to deliver a complete feature.
At Sprint Planning time, the teams realize that they must carefully choose PBIs that go together in order to deliver a sensible product increment. It takes a "front-end" PBI and a "back-end" PBI to deliver one customer-visible feature. During the sprint, the two teams find themselves slowed because they have to coordinate with each other. Often, they start to point fingers at one another as problems arise that transcend the ability of either team to address independently. Neither team can succeed (i.e., deliver a feature) without the other. Freedom of action, independence, ownership, and commitment start to fade as driving factors and we find ourselves back in the morass of complex, interconnected waterfall-style plans.
Dependencies! Integration! Is there a better way? There is. This is a case where the back-end system is not delivering customer value.
Try this: reorganize the teams. If possible, make them into one single cross-functional scrum team. If there are too many people for a single scrum team, and if that many people are really needed, then create two cross-funtional scrum teams. In this case, what I mean by "cross-functional team" is that each team will be able to develop front-end, back-end, and test software in order to deliver fully-formed, fully-tested customer features. They will not need to go outside of themselves in order to complete the PBIs.
With this organization, your single Product Backlog will consist of correct, well-formed items that describe customer-visible value. Cross-team dependencies will go away, since the dependencies between the client and the server components are resolved within each team. No more finger-pointing. No more need for careful coordination. You can even move to separate sprint planning once the two teams have chosen items from the single, unified Product Backlog.
This is a great way to handle client-server architectures in Scrum. All development activity is focused on delivering completed features to the end user, and everything conforms to the best ideals of Agile software development. Next time we'll talk about what to do when the software doesn't deliver value to an end-user.
To Whom Must We Deliver Value?
I was working with a team that was adopting scrum. We were starting to talk about the Product Backlog and what a well-formed Product Backlog item (PBI) looks like. I mentioned the idea that a PBI represented some value that the team wanted to deliver to its customers, the users of its software. This occasioned some perplexed looks, and one of the people on the team said, "But our software doesn't have customers!"
We rapidly established that in fact the team did have customers, but the customers were not end users. This team built a back-end service that was meant to be shared by applications which were built by other teams in the company. It was essentially invisible to end users, but it provided huge value to application developers, allowing them to concentrate on building end user value by using functional building blocks provided by underlying, back-end services. This approach was used by their entire company and resulted in lots of good, stable, reliable applications with the cost of application infrastructure amortized over the many apps that used it.
One of the things we try to change when we become Agile is the way we decompose work. Rather than decompose 'horizontally' into components, we decompose 'vertically' into features. This vertical decomposition is what we mean when we talk about user stories that deliver value to the end user. It is a key tenet of Agile thinking that we build vertical slices of the system that each deliver some visible value to the users of the system. This can be tricky for people to internalize.
Coaches and trainers and various bloggers and others will get very dogmatic and judgmental when people talk about writing user stores that aren't aimed at end users. I was once accused of supporting "outmoded and repressive management power structures" when I talked about the possibility that you could deliver value to somebody other than an end user! Sensitivity on this topic is good, because often people will get it wrong as they're learning to be Agile, but the fact is that there are times when it is correct to say that your software doesn't deliver value to end users, but at the same time, it does deliver value to somebody.
Here's an example. Suppose you work at a company that builds specialty operating systems. You might never see an end user because the users of your product only use it via an API. Yet it certainly stands to reason that you ought to be able to use Agile methods to build your software. The same holds true for teams that build device drivers, and also for teams and companies that build Internet-connected services meant to be used by a variety of applications. While it seems like these sorts of software don't deliver value to end users and therefore can't properly be addressed using Agile methods, nothing could be further from the truth.
In my opinion, at least.
I intend to continue this discussion over several blog entries in the coming weeks, and by the time we're done you'll be able to hold your head high even if you don't deliver value directly to end users. I promise.
We rapidly established that in fact the team did have customers, but the customers were not end users. This team built a back-end service that was meant to be shared by applications which were built by other teams in the company. It was essentially invisible to end users, but it provided huge value to application developers, allowing them to concentrate on building end user value by using functional building blocks provided by underlying, back-end services. This approach was used by their entire company and resulted in lots of good, stable, reliable applications with the cost of application infrastructure amortized over the many apps that used it.
One of the things we try to change when we become Agile is the way we decompose work. Rather than decompose 'horizontally' into components, we decompose 'vertically' into features. This vertical decomposition is what we mean when we talk about user stories that deliver value to the end user. It is a key tenet of Agile thinking that we build vertical slices of the system that each deliver some visible value to the users of the system. This can be tricky for people to internalize.
Coaches and trainers and various bloggers and others will get very dogmatic and judgmental when people talk about writing user stores that aren't aimed at end users. I was once accused of supporting "outmoded and repressive management power structures" when I talked about the possibility that you could deliver value to somebody other than an end user! Sensitivity on this topic is good, because often people will get it wrong as they're learning to be Agile, but the fact is that there are times when it is correct to say that your software doesn't deliver value to end users, but at the same time, it does deliver value to somebody.
Here's an example. Suppose you work at a company that builds specialty operating systems. You might never see an end user because the users of your product only use it via an API. Yet it certainly stands to reason that you ought to be able to use Agile methods to build your software. The same holds true for teams that build device drivers, and also for teams and companies that build Internet-connected services meant to be used by a variety of applications. While it seems like these sorts of software don't deliver value to end users and therefore can't properly be addressed using Agile methods, nothing could be further from the truth.
In my opinion, at least.
I intend to continue this discussion over several blog entries in the coming weeks, and by the time we're done you'll be able to hold your head high even if you don't deliver value directly to end users. I promise.
Why Am I Here?
Hi. My name's Alan and I'm a waterfallaholic. Yes, it's true. I've been clean for almost 5 years now, but before that I used waterfall daily for over 20 years. I was both a victim and a perpetrator of waterfall, being alternately driven into situations in which I could only fail, and then driving others into the same kind of situations. Its been hell, I can tell you.
"How did it happen?", I often ask myself. I was always a caring manager who wanted his people to succeed. And they often did. And even when they failed, we almost always found a way to describe it as a success anyway. Well, you see, there really wasn't a choice. We failed so often we had to get good at revisionism and denial because it would have caused too much pain to face our actual lack of success with no way to improve.
Then came the day that I discovered Scrum. Wowee! It made a bunch of sense to me long before I actually tried it. And even the first awful, awkward, half-baked attempt that I and my team made was better than the kind of software development we were used to. We stuck with it and we released an awesome piece of software.
That experience led to lots of continuing self-education and an oddly strong urge to become part of the Scrum movement. I wanted to be a part of changing the world of software development to this new way of working.
So I have emerged. I intend to spend my time here contributing my own knowledge, experience, and creativity to those that want to partake of scrum, and I hope to learn from many of you, also. My general approach will be to focus on the practical and pragmatic. There is enough theory and nuance and silliness out there, but there isn't enough hard, practical advice. I hope to start providing some. If you've got problems or questions related to scrum, post them here and I'll be glad to give you some answers based on my 5 years' experience with Scrum.
I'm utterly new to blogging, by the way, so please be patient as I figure it out.
alan
"How did it happen?", I often ask myself. I was always a caring manager who wanted his people to succeed. And they often did. And even when they failed, we almost always found a way to describe it as a success anyway. Well, you see, there really wasn't a choice. We failed so often we had to get good at revisionism and denial because it would have caused too much pain to face our actual lack of success with no way to improve.
Then came the day that I discovered Scrum. Wowee! It made a bunch of sense to me long before I actually tried it. And even the first awful, awkward, half-baked attempt that I and my team made was better than the kind of software development we were used to. We stuck with it and we released an awesome piece of software.
That experience led to lots of continuing self-education and an oddly strong urge to become part of the Scrum movement. I wanted to be a part of changing the world of software development to this new way of working.
So I have emerged. I intend to spend my time here contributing my own knowledge, experience, and creativity to those that want to partake of scrum, and I hope to learn from many of you, also. My general approach will be to focus on the practical and pragmatic. There is enough theory and nuance and silliness out there, but there isn't enough hard, practical advice. I hope to start providing some. If you've got problems or questions related to scrum, post them here and I'll be glad to give you some answers based on my 5 years' experience with Scrum.
I'm utterly new to blogging, by the way, so please be patient as I figure it out.
alan
Welcome
Welcome to my blog. Please check back soon for new entries.
