Tag Archives: agility

by

Essential Skill for Enterprise Software Development – Turn Uncertainty into Certainty

In most software development work at the office, I exercise a skill, which I can only think of as ‘turn uncertainty into certainty’.

Uncertainty

Some months ago, I was one of the ‘architects‘ on a project. The project lead told us that this was an ‘assessment’ project. We were not sure what that required us to do. We asked the powers that be. Their answers did not remove the confusion.

After a bit, this much became clear; we had to discover information that would help the client approve or reject the project. In addition, the project lead also wanted these; a Business Requirements Document (BRD), an Architecture Document, a Test Strategy Document, a Cut-over Strategy Document. What information these documents must contain, always seems vague to me.

Our business domain is vast. The BRD can get pretty detailed. How much detail do you need for a yay or nay decision? The analysts did not know. The project lead’s answers did not help much.

Regardless, we had to deliver something. Our jobs were on the line. My project lead needed something that the client could accept. Her job was on the line. The client needed something that was more than they already knew. Otherwise why engage us at all?

Certainty

What do you do? I sort of knew what to do. I had been to this rodeo before.

  • Give your lead something quick. It must be clear enough to let her immediately know if she can use it. Take the feedback into account, and make another small, quick experiment. Continue that till you arrive at something adequate.
  • Accept the burden of research and discovery yourself. Present the information such that the audience only has to say yes, or no. Don’t keep asking, what do you need. Instead, show what you have produced, and ask, does this work for you. Give folks something concrete to react to.
  • Keep the frequency of this interaction high. She has to see you digging, and adjusting. That is good for morale, all around. And if you go off on a tangent, both of you have to discover this fast.
  • Finally, you have to be ready to make a mistake. Yea, the work takes some courage. If you are lucky, your organization will make it safe to learn by trial and error. If not, well, who told you this was easy?

I know the types of information that characterize software solutions to a business problem.

  • Essential business requirement.
  • Specification of a solution to that essential business requirement. Broadly, you can often describe the solution in two different ways
    • A technology agnostic description
    • A technology-centric description

I realized that this conversation related to the technology-centric specification of the solution. So I studied the matter in question till I was able to put together a couple of technology-centric views of the solution.

  • A system-centric specification of the business process, in BPMN 2.0
  • A UML Component Diagram, which laid out software components that folks readily recognized; this also laid out how the components depended on each other.

As luck would have it, both the project lead and the client found this useful. This became the Architecture document.

Progress

I was still not certain that I had enough information for the ‘assessment’. I would wager that at that moment, neither were my project lead nor the client. It did not matter though. They saw that I knew the material that I presented. We went from uncertainty to some certainty. And they decided that if I did it once, I could do it again. That was progress. Onward.

by

Nobody told me I had to be a teacher

A Tech Lead has to be a teacher? Why didn’t someone tell me?

We have this C# method. It used to be good. Small. 25 lines or less. All at one abstraction level. See Bob Martin.

One of the kids, from offshore as it happens, had a bright idea. Next morning I wake up to find that the method is now a 100 lines.

I want to tell the kids. The method is too large. No method should be more than 25 lines. And they will chop it down pronto. They are good kids. But. There is no telling how they will chop it down. If they know how to tell a story in simple, clear steps, I have not seen evidence of it yet. They can’t seem to find the shortest, most direct route, between A and B.

Ask them how to go from D.C. to Baltimore.

They will come up with this. I-495 from National Airport to I-270 and Frederick. Then take I-70 to Breezewood. Break East on the PA turnpike to Harrisburg. Finally, come down I-83 to Baltimore.

That was fun. We got to write a lot of code. Oh what a lovely route it was.

They won’t stop, look around, and find 295, the Baltimore Washington Parkway, a straight shot between the hearts of D.C and Baltimore.

So I have to teach them how to chop the method down. But there is a problem. I know how to do the work. I don’t know how to teach it to another person.

I can say, make sure all of the code is at a single level of abstraction. They have no idea what I am saying. I don’t blame them. What does the word ‘abstraction’ even mean? I don’t know how to describe it man, I just know it when I see it. You know the button that starts your car. That’s an abstraction. You know what I mean? You don’t? Well, bloody hell.

So now on to Plan C. I redo the method myself. You know, I give them advice, and an example. Guess what happens. Nothing. Two days later the silly drama repeats itself.

It turns out, they could not care less about Clean Code. They know the programming language. They know some libraries. They are decent at problem solving. They get a kick out of flipping switches and seeing results. They are having fun. They feel no inclination to examine what they are doing. Stop, step back, dig deep, see under the surface, unlearn old habits, cultivate new habits. Further, after a couple of Sprints, they also learn that I will clean up the code myself.

It took me a long time to understand how to write Clean Code. It took me much practice to do it instinctively. Do you know how much I rewrite? How am I going to get the kids to adopt a regimen of study and practice? How am I going to get them to show interest and sustain it? How am I going to get them to care?

I am only a working engineer. You are asking me to not only teach, but also to motivate.

All of this, I have to do while a project is going on; under the gun, to deliver something.

It is not going to happen.

You are not going to get Clean Code.

Unless. You hire the right people.

by

Focus on skills rather than role

The project manager said, that is not your role, stay in your lane. I held my tongue. But it struck me that I no longer understand the fixation on roles.

While developing software, we must make certain choices. Some of these choices are expensive to change if you get them wrong. These choices constitute architecture. See Grady Booch. Architectural decisions must happen. How does it matter who makes these decisions, as long as they know what they are doing? We need Architecture. We don’t need Architects.

The same argument applies to other work. We need business analysis, we don’t need business analysts. We need testing, we don’t need testers. You catch the drift.

If one person can do business analysis, and solution design, why not let them do it? If one person can write code and test, why not let them do it? With each fewer person in the team, you avoid an information hop. With each fewer information hop, you avoid some information loss.

Here is another argument. A designer must know the business that she creates solutions for. Why not let her learn the business first hand? Let her do the business analysis. A developer, makes better choices in the code, when he knows the essential business. Why not let the developer talk to the business? If the developer has the necessary skills, drop the middle man. Knowing what Agile has taught us, do you still want a developer that cannot test? Let the developers test; eliminate a whole moving part in pipeline.

If one person can do a job, why would you want three? If three people can do a job, why would you want six?








by

Developers must know the business domain – I

Knowledge of the business domain is essential to developers.  They must know the business as well as the business folks know it.

We have all worked in environments where the business analyst’s word is gospel.  The analyst specifies a solution, and the developer translates it verbatim into code.

This approach to software development is less then optimal.

Blind football

Imagine sending a running back onto the field blindfolded.  We tell him, never mind that you cannot see a thing.  The analyst will relay  instructions to your ear.  Follow them to the letter and Bob’s your uncle.

  • Run 6 yards on a 37 degree angle to the left.  Your left, not mine.
  • Now tack right, 82 degrees, and run 15 yards at a speed of 26 miles per hour.
  • Wait, 300 pound linebacker at 7 ‘o’ clock.  Wheel, dummy, wheel.
  • Uh oh, too late.  No, wait.  The linebacker got tripped by his own cornerback!

See, the defense has blindfolds on too.  In fact, all 22 players on the field are blind as bats.  They are unseeing puppets, lumbering about, whose strings the business analyst is pulling.  Don’t you think there will be stumbles?  You bet there will be.  The business analysts have to be superhuman to get everything right all the time.  Your team must loose the blindfolds.

Pre-empt the bug

Business folks and analysts are as fallible as the next person.  There will be holes in the information they provide.  These gaps can cause  errors.  Developers must recognize and fill those gaps so that they can avoid those errors.  The alternative is to let the error happen, hope that someone catches it, then fix the error.   How can this ever be better than avoiding the error in the first place?  

by

Agile, by First Principles

Agile gives me the warm and fuzzy, because like all good systems it can be characterized by a small set of rules, first principles, from which we can derive all other relevant lessons.

first principles

Arguably, the Agile Manifesto, is the most famous attempt to lay out the first principles of the agile approach to software development.  The Agile Manifesto comes in two forms – an elegant and concise one, which is shown below, and a slightly longer, more expository one that I will leave you to discover.

Shorter Agile Manifesto

The problem with first principles

First principles are distillations of wisdom that practitioners gained only after a lot of experience.   For that very reason, they often make little sense to the newbie engineer.  We read the words and some of us ask, “Really?  Why ?”.  We don’t have an answer.  I know that is how it was for me.   Eventually, I acquired the critical mass of hard knocks that were necessary to see the inevitability of those first principles.

These days I seem to practice Agile almost instinctively.   So much so, that I struggle to explain what I am doing, and why I am doing it.   In trying to unpack how I go about software development,  I tried to write down the working set of principles that I work by.

Once the words were on paper, I could see how they derive from the Agile Manifesto.  It reminded of a line from Gandhi, “I’ve traveled so far. And all I’ve done is come back… home.”

A very personal agile manifesto

Below, you will find my working principles for agility.  Notice that my words don’t exactly match those of the Agile Manifesto.  That is as it should be.  My own personal manifesto, so to speak, is necessarily colored by my particular work experiences, and my personal strengths, weaknesses and prejudices.

Again, let me emphasize, this is not meant to be consumed blindly.  Ask yourself why this is valid. Think about what implications these ideas have.  Don’t be surprised if you do not understand or even agree with some of these.   This works for me; this, among other things, makes me an effective IT worker.

  • The only acceptable ‘status’ is working software that delivers business value.
    • Don’t tell me the status. Prove it.
      • Where is the code? Let me read the code. Let me see it running.
      • Where is the test? Is the test correct? Is it adequate? Let me see the test working.
  • The earlier you know the status the better.
    • Short iterations.
    • Frequent feedback.
    • Continuous integration.
  • If you can’t answer the question, “what is done, and what remains”, in terms that the business understands, you’ve got nothing.
    • User stories, in strictly business terms.
  • Change is the only constant.
    • You will never get correct nor complete business requirements at any one instant.  The same applies to solution specifications.  Roll with it.
    • No design nor solution will ever be right the first time.  Roll with it.
    • Priorities will change.  Roll with it.
  • Information is indispensable.   Documentation, and meetings are incidental.
    • Putting words on paper, and communicating are two different things.
    • Just because you talk, talk, and talk, does not mean you are communicating anything useful.
  • If you are not putting software in production, for business to do business with, you’ve got nothing.
    • All the process in the world, all the fancy tools, the “best and brightest” people, mean nothing, if you are not delivering.
    • The answer to every question of the kind, “is this the correct process, is this Scrum, is this Agile”, is one simple thing.
      • If it helps you deliver, yes.  If you are not delivering, none of it matters.
  • “No battle plan survives contact with the enemy“.
    • Human beings are unreliable.  Human judgment is unreliable.
      • Estimates are less correct, the farther out into the future they extend.
      • You will never anticipate everything that can go wrong.
      • Every process will break down.
      • Remember, Eisenhower’s advice, “In preparing for battle, I have always found that plans are useless, but planning is indispensable”.
    • You must be able to adjust and keep moving forward.   How?
      • There are no short-cuts.
      • This comes entirely from the attitude, ownership, knowledge, and skill, that people on the ground can bring to bear.
by

Is it a Bug or an Improvement – Irrelevant to agility

I see development teams struggling with the question – is this a bug, or an improvement.  A team that is agile (exhibits agility) would not care.

All the same to me

Tickets come my way.   Some are labelled bugs, and others, improvements.   To me, whose only mandate is to get the damn work done (aka agility), they all look the same.  What I do in response to either a bug or an improvement, is exactly the same.

All of the work requires analysis.   Gather all of the information that is available (documentation from client and analysts, production data, existing code, other tickets,  tests), and separate the essential business requirement from the solution that supports the requirement.  Then make sure that all stakeholders (clients, analysts, managers, developers, testers) have the same view of the matter, problem and solution.  Often, what they ask for is not what they need, and it is sometimes necessary to improve the solutions they specify. This requires constant and nimble communication.   Next construct the solution, which includes testing what we have constructed.  Finally, deliver the solution.

Every ticket is this same dance.

Why care, exactly

I can only think of two reasons for fixating on the difference between a bug and improvement.

First, the green-eyeshade brigade use the difference to figure out who to charge for the work.  A bug forces the development team to swallow the cost.  An improvement can be thrown into the client’s bill.

Second, it might help us figure out who to blame, or to use a more charitable perspective, it might point out where there is room for improvement.  A bug implies the developer messed up.  In cases where the bug is discovered in production, the finger sometimes points to the tester.   An improvement implies the business analyst, or perhaps the client missed something the first time around.

Of the above two reasons, I have sympathy only for the former, the billing problem.  This is mostly because I am low on the totem pole, and know very little about money matters.   Allow me to punt on this.

The latter reason leaves me cold, as you will see below,

What am I gonna believe – statistics or my lying eyes

Numbers can lie.

It is hard to have faith in statistics that classify work as bugs and improvements, when everyday I see my comrades-in-arms struggle to distinguish between the two.  More often than not, we shove tickets into one bucket or the other so work can move on. Typically, some power-that-be is breathing down our necks, or the task management tool is forcing us to make a selection.  Come time to review the work, we all know that the pretty pie charts, which the managers pass around, are nonsense.

I don’t need statistics to know the folks that I work with.  

I work with business folks, development managers, analysts, developers, testers, tech-writers, and so on.   After I spend a couple of weeks in the trenches with them, I know what their strengths and weaknesses are (don’t look now, that’s agility).

Take a developer for instance.   I read a developer’s code.  That tells me how she thinks through a problem.  I know if she can tell a story in simple, straightforward terms.   Can she find the shortest, most direct path between points A and B?

Consider a business analyst.   I read the documentation he creates.  That tells me if he simply knows the business or if he indeed is good at observation and analysis.  Does he see only the surface of things, or can he lift the hood, and identify the patterns and sub-structure that the surface covers?  I will know if his communication skills are adequate.   Can he accurately, clearly, describe what the business is, and what they are asking for?  The more I know the business (agility) the easier this gets.

I use the applications that they specify and build.  I know if they have empathy.  Do they know their users?  Can they walk in the user’s shoes?

I watch how they negotiate one on one conversations, and meetings.   This tells me if they know how to listen.

You get the idea.  Every little thing that a person does is a breadcrumb I can follow, especially if I know how to do that work myself (agility).

My recommendation – chuck it

If at all, only the bean counters need to worry about whether a piece of work is a bug or an improvement. Hide this question from the people that actually do the work. This question is irrelevant to the conduct of the work.   If you hear someone in your development team kvetching about bugs and improvements, make them buy lunch for the whole team (agility).

by

Focus on Agility, not Agile

For some time now, folks have been emphasizing that we have lost sight of agility, while frantically pursuing Agile.   There is little value in dogmatically following one Agile methodology or the other, Scrum for instance, while loosing sight of underlying purpose of such methods(in a word, agility).

So much Agile, so little Agile

To put it another way, Scrum, in and of itself, is not important.  Rather, why Scrum makes the recommendations that it does, is the important thing.

Take just one small example.

Scrum recommends we have a daily standup meeting.   I have been in teams that hold these meetings religiously.   However, it soon becomes clear to everyone attending the meeting that we are just going through the motions.   The meeting is just another way to waste 15, to 30 minutes of time every day.  In these environments I learned precious little in standup meetings.  Well, I did learn how many different ways there are to talk a lot without saying anything.

When I really want help from a team member I find a way to talk to that person on my own, one on one.   If someone else wants something from me, they come and find me, either electronically, or physically.

If I want to learn the status of the work, in my capacity as a tech or team lead, I pull down the code, build and run it.   I test the code myself, and I learn things that nobody tells me in standup meetings.

Information is essential.  The meeting is not.

If I was working with peers whose skills I had confidence in, and whose word I could take implicitly, the standup meeting may give me the information I am seeking.   However, more often than not, what I hear in a standup meeting falls well short of a full wallet.   Fine. I am not an engineer for nothing.  I don’t need that standup meeting to know exactly where each of my team members are.  I have other ways of skinning this cat.  This is not Scrum.  However, it surely is agility.

by

Process is very often, much ado about little

The first principle in the Agile Manifesto is “Individuals and Interactions, over processes and tools”. A recent development task illustrated that point starkly – skill trumps process.

Time’s a wastin ….

I was working through a weekend, exhaustively specifying the UI (mockups, WORD docs, UML State diagrams) for a recent user story, when it occurred to me that we were wasting our time.

Here is more or less the user story I was working on.

As a documentation processor, I must be able to review all of the documents in a mailbag. Upon review, I must be able to accept, or reject each of these documents.

In the time that it was taking to describe the UI to its last gory detail,  I could create a working prototype of the UI, which would be close to 80% of what the user needs.  The business folks could take the prototype for a spin, and give me feedback, which could quickly iron out the remaining 20% of the work.

See, we are building this for processors in an insurance company.   They are not looking for sophisticated, space age UI.  They just need something that is easy to understand, learn, and allows them to do the work efficiently.

Between the business analyst and me, we could have the UI squared away in a couple of weeks – a single sprint.  Add a tester if you must.

I will test every damn line of code I write anyway, before this leaves my hands.   The tester is only a second line of defense.   Even without that tester, I can get this very close to done.

So why am I specifying the UI when I can just build the thing myself?  I am having to do this because, collectively, the primary resources that are assigned to this task cannot or will not, produce an effective UI on their own.  That amazes me.  I am shaking my head as I write this.   If you have several years of experience with this problem domain, with these business analysts, with these end users, and with the same UI technology, you should be able to take the user story, fill in all the missing details, and end up at the UI.

Again, here is the user story, for reference.

As a documentation processor, I must be able to review all of the documents in a mailbag. Upon review, I must be able to accept, or reject each of these documents.

Let’s think through this.

Analysis

  • Users have to review all the documents in the mail bag.
    • This means you have to list the documents to the user
  • So how do you present a list of documents.
    • A table, where each column is some attribute of the document, and each row is a document.
  • How do you make it easy for a user to study a large list of data that is in a table?
    • Allow filtering and sorting by various attributes.
    • Break up the list into several pages, and allow the user to page
      • Or simply allow the user to scroll up and down the large list.
  • How do you help the user make changes to large amounts of data safely, and correctly?
    • You must ask the user to confirm a large change.  Give her a chance to back out.
    • You must provide the user a way to undo a change.  Mistakes will happen.
  • What attributes (columns) of the documents must be included in the list
    • Leave out the attributes of the documents that are implementation-centric, which users have no need to know.
    • Pick the attributes that are business information.  Make a guess on which of these the user might be interested in.   Changing this list after review should not be hard.

Can’t the developer do this?

Analysis

If you have been developing UI for any time at all, you should be able to do the analysis I just did, and arrive at a similar, if not the same place.

Business Info

You have been working in this domain for several years.  That means you must already have all the business information you need.

You must know the business-centric attributes that characterize the mailbag and documents.   These become the columns of your listing, and suggest what the user can sort and filter on.

Language and jargon that end-users will recognize must also be familiar to you by now.  This is where static labels, feedback messages and such will come from.

Implementation

You have been working with your UI framework for several years.  So you should know how to implement the various UI features mentioned above – a table of data, sorting, filtering, paging, scrolling.

But none of this happened

But none of this happened, and a UI designer had to be brought in to spell everything out.   Why?

The Developer

Though they were well-versed with the UI framework, the developers have little knowledge of, or interest in, what makes an effective UI.

They are happy to be told what to build.  They want to be told what to build.  When left to their own initiative earlier, they produced a UI that so defied common sense and business reality, that the end-users’ job turned into a labor-intensive, error-prone, hell.

The Tester

If the testers know the lingua franca of the business (English, in this case), if the testers know the business, and if they know the end-users, the testers can judge if the UI satisfies the business need, simply by relying on the 2 sentence user story.

Unfortunately, testers’ familiarity with the business is uneven.  They are simply kids that compare a spec to delivered software.  If the spec is incomplete, or incorrect, these testers are thrown off course.

Further, more often than not, the testing leadership subscribes to the view that testers must only work off an exhaustively detailed spec.  Applying their own knowledge of the business, their own analytical and communication skills, is considered risky. The focus on learning the business themselves is weak.

Manager

Well, managers have all the power, which makes them responsible for everything, doesn’t it?

Who are they hiring?

The UI developer does not exhibit knowledge of effective UI design.    So how did we end up hiring him?

Say the manager that is evaluating the developer does not know anything about UI design himself.   So the manager cannot determine the developer’s competence in the matter.  That is reasonable and common.   A manager is constantly confronted with problems in which he does not have direct expertise.   Yet, she must hire people that will be responsible for solving that problem.    In that situation, a manager has to be able to recognize competence (and conversely, incompetence) as a characteristic separate from concretely observable skill.   Competence has an aura, a body language, a speech pattern, a look in the eye, as does incompetence. You have to be able to smell the bullshit before you see it.

When managers neither have concrete expertise, nor do they have a nose for fakery, we end up with these half-baked developers that require to be spoon fed.

Bad drivers

Many resources are able to learn and do more if we create the right environment.  This is usually some combination of large grained carrot and stick, coupled with the pushing of buttons that we can only learn by getting to know the resource personally.

Effective UI design for the corporate world, is a skill that can be learned by just about anyone in a few weeks, or over the course of a few UI development tasks.  If a developer has worked on UI development for going on three years, and still does not have a coherent, useful view of the matter, the leadership has been asleep at the wheel.

The same argument applies to the testers.   The management enabled them to be unthinking, ‘garbage in garbage out’ type grunts.

Skill trumps process

What a business analyst and a skilled engineer can take care, is now distributed over a whole platoon – The business analyst, the UI designer, the developer, the tester, tech and test leads to oversee the grunts, managers to oversee all of this.

Where the work could simply be a conversation between two people, now is a multi-step workflow involving many more people than that.  Two people getting a task done is just work.    Eight people, each with their own inputs, and deliverables, working on narrow parts of the whole, and that with their vision constrained by blinders, is a process.

What does the process buy us?   Nothing that I can see.  I see overhead. An 8 to 10 person team requires more management and book-keeping than a 2 person team. I see a machine with more moving parts, which exponentially increases the complexity, the amount of co-ordination required, and the number of ways the process can fail.

One or two committed, skilled engineers can replace the whole process. Why not learn to identify, hire and hold on to such resources? Why the fixation on process? Do you want get work done?  Or do you want to run a process?

by

Story points of a user story that spans sprints

We start a story in sprint 7, but we finish the story in sprint 8. Should we count those story points against 7, or against 8?

Barking up the wrong tree

We are asking the wrong question.

It does not matter whether we add those story points to sprint 7, or 8. That line of thought tells us nothing useful about how we are performing the primary task at hand – deliver correct, well built software in a timely manner.

Make no mistake, when a user story slips into a second sprint, you have a problem with how the work is going. That problem, whatever it is, demands examination and remedy. However, deciding which sprint to stick the story points in neither helps the examination of what went wrong, nor does it contribute to correcting the failure.

Big story

The user story may have been too big. Perhaps we bit off more than we could chew. We should have broken the user story into smaller ones. Watch out for that next time.

How do you split a story into smaller ones? That is a separate question. There are a lot of references on that, which I’ll leave you to research.

We are not efficient

Say we decide that we cannot break the story into smaller pieces. Perhaps something is not quite right with our productivity.

In my current place of work, we get issues that can be finished (analyzed, fixed, tested) in a couple of days by a developer that knows the domain, and the system. However we also have folks that take a couple of weeks to finish the same story. Their work often span sprints. These folks have to come up to speed. There is your problem. Address it.

Perhaps the developer finishes his part, but the issue languishes with the testers because they are swamped with other things. This exposes problems with how we have organized our teams. Protect team members from being dragged into work that is extraneous to the current sprint.

We should have known early

We should have known that a story would not finish, well before the end of the sprint, and we should have taken remedial action right then.

If we know our team, and our engineering environment, we should have been aware even before we started, that we would not finish a story. If we cannot make such judgements even after a couple of sprints, the sprints are not teaching us anything. If we are not gaining a more accurate estimate of our team’s capability, sprint by sprint, we are not being Agile. What obstacles keep us from understanding our team’s capacity to deliver? Investigate that.

Sometimes we misread a user story. We clearly see the story only after working on it for a couple of days. At this point it should become clear whether we will finish the story or not. This kind of early feedback is the cornerstone of the Agile way. If you become aware of an out of control story only at the end of a sprint, you are not being Agile. Why is this feedback not happening? Or is it happening, but the information is worthless? Perhaps your team is dissembling, and the scrum master cannot tell fact from fiction. Look into this.

Velocity – Weather or Climate?

It is not hard to see why we fixate on which sprint earns a partially completed story’s points. We are trying to figure out how much our team can deliver in a sprint; the so called Velocity.

Do not get too hung up on Velocity. As Mike Cohn of Mountain Goat Software points out, Velocity is characterized by a dichotomy that is very much like the one between weather and climate. On any given day, weather can be good or bad. You can make valid generalizations about the weather of a particular location, only after observing it over a large span of time. We have a word for that. Climate. Think of Velocity as climate, not weather.

The number and size of user stories that you start and finish within a single sprint, will vary from one sprint to another. Don’t worry about it too much. Over several sprints, you will get a good measure of how much work you can do. Over several sprints, Velocity will reveal itself.

Here are three slides from Mike Cohn’s Scrum Master training, which also make the above point.

Velocity Fluctuates from Sprint to Sprint

Velocity Fluctuates from Sprint to Sprint

Velocity - Some are Outliers, Some are Typical

Velocity – Some are Outliers, Some are Typical

Infer Reliable Velocity From Sample

Infer Reliable Velocity From Sample

Focus on learning from the trials and tribulations of each sprint.  Address these issues as you become aware of them.  Velocity will take care of itself.

by

User Stories and Building Blocks – Another Difference

An earlier post described how the Agile philosophy implicitly divides software development into two types of work – user stories and building blocks. In addition, the post delved into how to distinguish between the two types of work. Here, I point out another seminal difference between user stories and building blocks.

How much is done?

During the course of a project, a critical question comes up again and again. Business stakeholders, and managers, keep asking, how much is done? What exactly is completed? What remains?

What answer do you think is most useful for them? Investigating that question reveals a defining difference between user stories and building blocks.

Status by User Story

This is a list of features that we must build. Clearly these are user stories.

As a customer service rep, I want to be able to generate an auto insurance quote.

As a customer service rep, I want to be able to email, fax, and mail a paper copy, to the customer.

As a customer service rep, I want to order a customer’s credit report.

As a customer service manager, I want to see all enrollments that are in process at this moment.

When a business stakeholder wants to know what is completed and what remains, we can simply point her to this list of business features. Is an item production ready? Is there a metaphorical green check mark against the item?

This list of work represents the value that business users are looking for, in the system we are building. Hence, the list of user stories communicates status that is immediately relevant to business, in an unambiguous, even visceral manner.

Status by Building Block

Now consider this list of work.

Build the data acces layer of the enrollment sub-system.

Implement the business logic of enrollment as production rules.

Build a REST service wrapper around the Enrollment API.

Build a web based UI for managing enrollments. This is meant for internal processors and customer service reps. This UI will sit directly on top of the business layer.

Build a mobile app for use by customers to manage their enrollments. This will talk to the REST web service.

If you tell business users, you have completed the data access layer, and business layer, does that tell them anything about what they really care about, the business features that we are building? It does not. Business stakeholders really have to wait till all of the above tasks are done before they can begin to evaluate what shape, and how much of the business features, and in what shape they have been delivered. Until then all is uncertain.

Out of this uncertainty is born magic status measurements like 35% done, 60% done, etc. These numbers convey little information that is useful for business stakeholders. Confidence in such status’ are low and always feel pathetically forced.

Thus

You can differentiate between a user story and a building block by what information they convey when we complete them. Completion of a user story unambiguously tells business what features are done, and what remain. Completing a building block leaves those questions unanswered.