Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
Software Development Blogs: Programming, Software Testing, Agile Project Management
Subscribe to Methods & Tools
if you are not afraid to read more than one page to be a smarter software developer, software tester or project manager!
In last week’s post, I wrote about how to integrate UI designers into the agile sprint. I said that designers should work as part of the team on the current sprint but should spend some of their time (perhaps even most of it) looking ahead at what is coming next.
But this raises a concern I’d like to address in this post. How do UI designers ensure a consistent design without having an upfront design phase in which they design the entire product?
Guide the Design Intentionally
First, designers intentionally guide the design of a system. Because an agile project does not have an upfront design phase, design is said to be emergent. That is, the design emerges over time. It is not created in a phase of the project.
However, the design does not emerge randomly. The design emerges guided by the skilled intent of the designer. The designer identifies areas of the system and designs those first. The designer then works with the team to build those, incorporates feedback from real users, and then identifies the next areas of interest to design.
This process is repeated iteratively and incrementally. The key is that each area is chosen intentionally by the designer as one that will provide insights into the remaining design issues. Design does not proceed randomly.
Think about how you might put together a jigsaw puzzle. You would not put a puzzle together by randomly picking up pieces and looking to match them together. Instead, you would probably start by finding the corner pieces, then the edges, and so on. With the entire border outlined, you might move onto a specific color or pattern. This approach could be described as both emergent and intentional.
Take Advantage of Incremental Delivery to Incorporate Early Feedback
A huge advantage to UI designers on agile projects is the ability to get actual feedback from real users early in the process. In exchange for giving up the ability to design an entire system upfront, designers get something very valuable in return -- this opportunity for feedback.
As designers learn to avail themselves of this feedback, they realize that the ability to change parts of a product late in the process outweighs the benefits of total freedom in an upfront design phase.
Think Holistically, Work Incrementally
Novelist E.L. Doctorow has said that writing a novel is like “driving a car at night. You never see further than your headlights, but you can make the whole trip that way.” I think the same applies to designing products.
A designer should have a vision for the full journey, but can make the drive seeing only as far ahead as as the headlights reveal.
On an agile project, designers need to think holistically but work incrementally. The designer and novelist both know where they are ultimately headed, but each gets there by looking only a certain distance ahead at any time.
Hofstadter's¬†Law is actually about self-referencing systems. The statement about how long it takes is a self-referencing statement.
The #NoEstimate community uses it as an example that¬†you can't estimate, because even when you do it's going to be wrong.
This of course willfully ignores the principles, practices, and processes of mathematical estimating. Both Parametric and probabilistic estimates.
In both these paradigms, parametric and probabilistic, uncertainty is the core driver of variance both Irreducible and Reducible uncertainties.¬†
Here's the well known approach to managing in the presence of unceratnty
Managing in the presence of uncertainty from Glen Alleman ¬† So what the #NoEstimates advocates fail to understand is that in the presence of reducible (epistemic) and irreducible (aleatory) uncertainty, actions must be taken to address these uncertainty and prevent these from unfavorably impact the project outcomes, as suggested in ...
In both cases¬†managing in the¬†presence¬†of uncertainty¬†means following Tim Lister's advice...
Risk Management is how Adults Manage projects
So when¬†Hofstadter's Law is used without addressing the reducible and irreducible uncertainties and the resulting risk to project success, the result is¬†Hofstadter's Law.
A self reference circular logic leading directly to project disappointment. ¬†Related articles Architecture -Center ERP Systems in the Manufacturing Domain IT Risk Management Why Guessing is not Estimating and Estimating is not Guessing
In any discussion of project management, software development, and business management, agreeing on a shared set of definitions is critical por progress in exchanging ideas. When standard definitions are redefined to suit the needs of those conjecturing a new approach, it makes it more difficult to have a meaningful conversation.
One recent example is the No Estimates advocates redefining the meaning of estimate and forecast. Where forecasting is NOT estimating, so the No Estimates moniker can be applied to what is essentially estimating,¬†
First let's look at some definitions of Estimate as applied to project and program work. The estimate is applied to something. Cost, Schedule, some technical performance parameter. So we can't just use Estimate by itself. It needs to be an estimate of something. Here's some things we can estimate and the processes of performing those estimates on projects that involve uncertainty. If there is no uncertainty in the project the need for estimating goes away. Just¬†observe the empirical data¬†and calculate the needed value - cost, schedule, or technical performance.
So now to the killer concept
If the project you are working has no uncertainty and therefore has no resulting risk, the need for estimating is greatly reduced of not eliminated. If there is uncertainty and resulting risk, then Tim Lister has something to say...
So no Uncertainty, No Risk, No need for Risk Management, low if any need for estimates of the outcomes of the decisions made the project participants.
Can This Really Be True?
Ask if your project has NO uncertainties? Nothing in the future that is unknown at the moment. No process that has any variance, in the past, now, or in the future. Nothing is going to change. All the work will run at the same efficiency as it does now. No defect will appear. No changing performance behaviors as the result of new development.
A bit about uncertainty. There are two kinds. Reducible and Irreducible. Reducible uncertainty is event based. That is there is a probability associated with the uncertainty coming true. For example¬†there is q 30%¬†probability¬†of rain today over the forecast area.¬†This is an event based uncertainty. To protect yourself from this uncertainty, depending on where you live, bring a rain coat.
There is irreducible uncertainty. This is the naturally occurring variances in the underlying system of interest. For example, I drive to the airport every Tuesday morning every other week to work at a client site. ¬†There is Reducible uncertainty around the weather. I'll look at the weather report to see what is going to happen. But given the weather, there will be an impact on the traffic. Snow or Sleet will have a different impact than rain or sunshine. This impact is a variances in the traffic flow which I have no control over. The only¬†protection for not missing my flight is to have sufficient time¬†margin
in the drive. On a clear day, not traffic, no other impediments, it's 45 minutes from driveway to my favorite parking spot on east side of DIA, Level 1. Margin is applied depending on the events and underlying processes of travel.
So when the term Estimate and its related term Forecast are redefined so estimating is not seen as estimating, it¬†pollutes the conversation. This conversation is critical to increasing the probability of success of projects in all domain.¬†
A question I’ve been getting a lot lately is whether UI designers should be part of the Scrum team and whether they should do their work as part of an agile sprint. It’s a big topic. So let’s dive right in.
The Two Goals of an Agile Sprint
There are really two things a team should be doing each sprint:
We all know that teams have to build new functionality each sprint. That is, after all, the purpose of most projects--to deliver new capabilities into the hands of users.
But teams also need to build new knowledge. A team should finish each sprint smarter than it started. Sometimes a team learns things about a technology it is using or about how users view the functionality it has built. Other times, a team might learn something about itself and how it is performing.
Both goals are important.
What UI Designers Do During the Sprint
During each sprint, UI designers should pursue the twin goals of building functionality and building knowledge. Within a sprint, a UI designer will be helping the rest of team turn a design into implemented, tested code while simultaneously thinking about the next feature (or two) to be built. This means, a designer is both in the sprint and looking ahead at what comes next.
The result is something like what is shown in the figure below. This figure shows that while coding and testing one part of the product backlog, the user interface designers will spend some of their time (perhaps a majority of it) looking further down the product backlog at upcoming items. Yet, it remains one team working on one sprint at a time.
The UI designer’s top priority must be to the work of the current sprint. If a team member needs a clarification on a design for a product backlog item being worked on in the current sprint, the designer stops thinking about next sprint and answers the question about the work of the current sprint.
How About Other Roles?
Pause for a moment and consider everything I’ve just written about UI designers. But think now about product owners, analysts, database designers, architects or perhaps anyone with a significant responsibility to think ahead about what is to come on the project.
Everything still applies. It’s just a difference of the amount. Designers may spend the majority of their time building knowledge, but they’ll still spend some time building functionality. And one of the other roles I just mentioned may do the opposite. Every role on an agile project will split its time between building functionality and building knowledge.
Avoid Perfecting the Design the Upfront
In giving the designer permission to look ahead, the agile team is not asking the designer to complete the design. Rather the designer should do just enough in advance that the product backlog item can be completed by the rest of the team in the later sprint when the team works on it.
At the end of the sprint, the team should feel that if they had received any less information from the designer, it would have been impossible to finish the product backlog item within the sprint. This means that some product backlog items may need to be looked at in massive detail (and more than one sprint ahead) whereas others may not need to be looked at in advance at all.
Additionally, any items a designer does look at beyond the current sprint should be chosen through discussion with the product owner. The designer wants to avoid working on something a product owner later deems unnecessary.
Does This Lead to Bad Design?
A common concern is that this could lead to a bad design. Wouldn’t it be better if the designer could think holistically about the entire system upfront? In next week’s blog, I’ll explain why working this way does not lead to bad designs.
Share Your Thoughts
How does your team work with its UI designers? If you’re a designer, how do you work with your team? Please share your thoughts with us below.
Agile teams are told to “embrace change,” which is the subtitle to Kent Beck’s wonderful Extreme Programming Explained book. Although an agile team can embrace change, the stakeholders in an organization must understand that change is not always free.
Most agile teams seems to understand this. They get that requirements changes can crossover into requirements churn, to use the traditional term for the problem. Scrum tries to solve the problem by including as part of its framework a rule that change is not allowed into a sprint. Once a sprint has started, change is kept out of the sprint, leaving the team to focus on what was selected to be worked on in the sprint.
This can work extremely well, but keeping change out of the sprint is sometimes thrown back in the face of the team. A product owner or stakeholder who is told that a change cannot be introduced will respond with, “But I thought you’re agile, and isn’t the whole point of being agile that you welcome changing requirements?”
Well, yes and no. A team can welcome changing requirements but that doesn’t mean those changes are free. Consider the following scenario:
You’re out to dinner and settle on chicken as the main dish. As the waiter walks away, you call him back and tell him you’ve changed your mind. You’d prefer the fish. No problem, he says. There is no cost to this change. The restaurant is not going to charge you for changing your mind (changing the requirements) five seconds into your order (five seconds into the iteration).
But, let’s make things a little more interesting.
Suppose the waiter takes your order for chicken and a salad to start. He brings you the salad, and you then change your order for the main dish from chicken to fish. My experience is that most restaurants will still not charge you for this. They’ll bring you the fish even though they may have started cooking the chicken.
There may be a real cost to the restaurant. But I suspect they write it off as goodwill, hoping you enjoy your meal and the courtesy they showed you. And they hope you come back more often because of it.
And let’s say you do come back. In fact, you come back every night. And every night, you jerk the waiter around by changing your order after he brings you the salad. The restaurant is incurring real costs because of you.
They may still be nice and not pass the costs of these changes onto you. But, if I were that restaurant, I’d pass a different type of cost onto you: I’d wait to start cooking your main dish until after you ate the salad so that we were both sure of your order.
Let’s consider one additional scenario. In this case, after eating the salad, you change your order of chicken to fish, as before. But before the fish comes, you call the waiter over and tell him you’ve re-considered and the steak sounds appealing.
Then, before the steak arrives, you call the waiter again and tell him you saw the linguine served to another diner and simply must have that. At some point, the restaurant has incurred real costs from all this switching and will charge you for it.
Change is not free.
You can change your order at the restaurant up to a point for free. You can change it after that and the restaurant will do all they can to minimize the impact of that change, but beyond some point there is a cost to changing.
The same is true on product development initiatives. We can and should embrace change. It is often why we want to be agile. But we can also educate our stakeholders so they understand that change introduced beyond a certain point in an iteration has a cost. And we can work together with them to minimize those costs.