Category Archives: Agile & Lean

A bit of Agile Transformation Haiku

One of the Agile Retroflections of the Day I submitted is this one, “What haiku can you write that reflects on your transformation efforts thus far?”

I’m a huge fan of haiku; it uses powerful imagery to convey messages. This was the one I came up with for my customer’s transformation thus far:

Strong burro works hard

Bureaucratic harnesses

But it’s pull, not push

I was inspired to use a burro as they are real workhorses ummm… really burros and because I know a fellow Agilista, Lisa Crispin, raises them.

But upon additional thought, I’d rewrite the haiku slightly to become:

Burro of strong heart

Bureaucratic harnesses

But it’s pull, not push

What would your haiku be?

 

 

Team Launch Misfires…

I’ve been conducting Team Launch workshops for awhile now; some for teams doing software development work and some for other types of supporting products.

I_love_my_awesome_teamI’ve noticed teams that go through a significant amount of effort on these types of chartering exercises seem to always be “awesome” compared to most of their peer teams. They get more done; what they get done is more on target with what the end user needs; and they have less post-deployment problems. I really don’t think this correlation is a coincidence.

My views on launching teams are 99% +/- 2% congruent* with Ainsley Nies’ and Diana Larsen’s views as expressed in their book Lift-off. (If you don’t have this book, go get it!) I had about 5 categories of agreement I used, but they easily collapsed into the 3 from the book: Purpose, Alignment, and Context. Now I use those.

Out of these I view Alignment as the most important one. If I can get to a team that is aligned in HOW they will work together, they can overcome the shortcoming in understanding of the purpose (or on a project where the purpose is emergent) and certainly they can handle an evolving context as they probably thought about those ever shifting sands.

The teams I see that are challenged almost always short change this area as it feels soft and squishy. Why should I understand what my co-workers value? Who cares how decisions are made – let the boss do it as he always has… Why do we need to think about what and how we celebrate things? Ignoring this ignores the first Agile Value: Individuals & Interactions over processes and tools. Launching teams correctly celebrates the former and ensures the latter is subservient to it. Every team I see struggling as of late has short-changed this Team Chartering, particularly around Alignment. A guarantee the missile will miss the mark.

Want more info on how to be successful? See my post on Excella’s blog. And/or get the Lift-Off book and think about what Purpose, Alignment, and Context mean in your environment.

 

*You’ll notice that the upper end of this is 101% which is where I think my congruent thoughts are most of the time…

Symptom of Anti-Agility: CRM Groups

Collapsed_Bridge_Narrower

I haven’t written in a bit (well I have actually, but on Excella’s Insight blog), but I wanted to write about an anti-pattern I am seeing in one of our clients. Many have written that management seems to think of “Agile” as only within development teams, and forget that this Lean and Agile thinking needs to permeate everywhere.  It’s a dysfunction to continue working on…

So let me give you the example I am seeing so we can talk in more concrete terms.

The organization has had a rocky past between central IT and the business. Software development is distributed in various business units as well as a central IT shop (I’m staying away from actual terms the customer uses BTW). Central IT also does considerably more though, such as manage the network, run a server farm or three, manage cloud providers, email and content management services, etc.

The complaints from the business have been articulated as (in no particular order):

  • I have to know who to call in order to get good service; any official channel for requests is difficult to know.
  • Service is often slow and paper/form intensive.
  • When I use any official channel, it doesn’t necessarily get routed to the right location.
  • I’m not told everything I need to do to get my request fulfilled, resulting in delays.
  • I don’t know the status on requests that have a longer time to fulfill, nor have I been told or know where to go to find out my status.
  • I’m uncertain if any feedback I provide is acted upon.

I’m certain everyone has seen these before in some mix.  IT also has a set of complaints:

  • People go to whoever they happen to know that is related to the request they want to make to get service. This eats into people’s time without management having much knowledge of it (perhaps the immediate supervisor knows, but no one else).
  • IT needs to begin a charge-back model due to budget restructuring that is removing a great deal of central ITs funding, thus more knowledge of requests and services is needed to be known. The manner in which requests are coming does not provide a means to track it.
  • The business sides doesn’t see the great work we are doing.
  • The right people in IT don’t receive the needed feedback.
  • IT has a blemished image/brand and are thus not viewed as a valuable partner.
  • The CIO can’t keep up with the requests given to him by his peers; too many are bubbling up and being made directly to him.

If you work in an IT organization, particularly as a senior manager type, how many of these have you seen? Before I go into how to handle these with some Agility, let’s look at what this organization is doing that I consider an anti-pattern; literally anti-Agility thinking.

The senior manager tasked with solving this sees this primarily as a communications problem in 3 areas:

  • Routing to the right people to do the work
  • Taking in feedback on ITs performance
  • Improving the communications on good performance (improving the “brand”)

To solve this, they are standing up a Customer Relations Group that will take in initial requests/requirements, receive feedback about performance during and at the end of the work and provide it to the group(s) that performed it, and get the word out on the good stuff IT does.

They are starting by creating a master catalog of services IT provides (which on the back-end will have costs associated with them). It’s unclear whether these costs and/or the parts of the IT organization that will perform them will be a part of this catalog.  So far not bad… They also will stand up a single intake service (along with an online form) to process these needs, then ‘interview’ the customer to get any additional information, and route this request to the proper parts of IT.  It seems at this point there will be a hand-off; what is unclear is how this hand-off will work if multiple parts of the organization are involved simultaneously. If software development is the primary concern, it will be handed off to a development team (or a new team will be stood up).

This new Customer Relations Group will also query the customers periodically to find out how well the various parts are doing and give this to the right part of the organization. It will also give any responses back to the customer. And finally it will create some marketing material and positive ‘press’ to help sell IT services.

To keep this from being a burden on the current IT organization, the bulk of this work will be contracted out to a big name firm that everyone respects. Sounds great doesn’t it!? Every organization needs this, right?

As well as intentioned at this group (and its contractors) may be, this creates several dysfunctions.

  1. This is actually adding an additional step that will actually slow requests getting to the right people. This will increase the time to service, probably decreasing happiness, perhaps not initially, but certainly in the long run.
  2. It adds a hand-off of information so that the people needing it are getting it second-hand. This will lead to greater misunderstandings between the groups that need to work together.
  3. Feedback and working communications are at least partly being removed from the group that needs them directly.
  4. There is an assumption that a one-size-fits-all intake process can accommodate getting all of the unique needs a customer needs to portray to a unique supplier. Requests for an email distribution list would be vastly different than one for a software development project, or just even business analysis services for a development project.
  5. Messaging (branding) will be coming from a third party not responsible for any of the results.

Even worse though, there are fundamental root-cause problems being masked over.  For example, why does the business feel feedback they give is not listened to and acted upon? This solution isn’t going to address this root-cause concern. What is causing the long lead-time for IT to respond to business needs? Why are we trying to create a standard process for intake and routing as opposed to simply better connecting people to those that would supply the services and give proper visibility into the incoming work, but allow a self-routing approach? Why do we need to do a charge-back for the services internally as opposed to getting the budget reallocated properly to pay for them?

So how would I approach these items? I’d start with challenging the fundamental way things are done. I would learn where are the bottlenecks causing the unacceptable lead-time. I’d investigate the root-causes to the image/branding and see how to solve those. I’d see how I could make a catalog of services attached to the people that provide the services and work them to create mechanisms that give me an understanding of the allocation of requests. And I would at least talk with the budget personnel to find out how I could simply get the budget allocated properly; if that couldn’t be done, I’d make my service costs transparent to those when they look up my services. If I wanted something Customer Relationship-like, I’d perhaps think about deploying customer relationship software to all the groups directly, if evidence showed it would help.

Bottomline: I’d reduce hand-offs and keep with the spirit of individuals and interactions over processes and tools. I’d do the simplest thing I think is in the right direction and then retrospect on how that is working for me.

 

TWEET Your Feedback

pixar-birds-wallpapers-movies-widescreen-images-157470

This post was prompted by Jurgen Appelo’s excellent post on giving a Feedback Wrap on Forbes.

I really like this post as it gives you an extremely useful way to express feedback in a manner that will help the receiver actually take action.  It also helps them become aware of future behaviors they may need to change.

Giving good feedback is important, whether it is to superiors, subordinates, or peers. Like Jurgen, I won’t claim to be perfect at doing this and more than once, I know I have provided useless and sometimes hurtful feedback. So to provide a bit of additonal advice as a wrapper around what Jurgen is recommending, I wanted to share an acronym I learned at Culture Camp DC 2012 from Chad Wolfsheimer of the Motley Fool.  The acronym is TWEET; here’s how it breaks down:

Take note of impact

This part is recognizing a meaning to the behavior you want to give feedback on; what is this behavior doing to you, others, a team, and/or the organization. If there isn’t any impact (or perhaps if it truly is trivial), then ask yourself is this feedback going to be useful?

Write down (organize thoughts)

Chad recommends writing down your thoughts, but he did offer up that due to the necessary timing you may not have this opportunity. None-the-less, take a mental step back and organize how you plan to present it; non-organized feedback will come across as a rambling complaint and not achieve what you want.  Using Jurgen’s Feedback Wrap technique is an excellent way to do this.

Empathize

Before jumping and giving feedback, try to understand the context the other person may have. Empathy in this case is not only what they may be feeling emotionally, but also what their mental model may be on why they are exhibiting the behaviors they are. Trying to understand this may help give you insight into how to deliver it so that it is received well.

design it be Effective

Using the Feedback wrap as guidance to organizing it and any insights you may have gained through empathizing, think through how the delivery can be made effective.  After all, if the feedback is ignored or it spawns a defensive mechanism, it probably won’t likely alter the behavior you want changed.

Time it appropriately

We’ve heard how feedback should be timely; Chad recommends and I agree to think about timing. Often just after the behavior is exhibited is the right time, but at other times it may be worth making a determination as to the most appropriate time to deliver the feedback to maximize its reception.

On top of the two great ways to look at feedback that Jurgen and Chad have presented, I also recommend including inquiry.  Asking a few key questions can help you both empathize AND open up the recipient’s mind about the behavior you want to change. Be careful what questions you ask though; for example ‘Why’ questions may put the recipient on the defensive. Try and use open-ended questions as well as this prompts some thinking.  Here’s an example of a question that may work –

After you presented your critique of John’s database design, what did you notice about people’s reactions, and in particular John’s, to your statements?

If the person you are providing feedback hadn’t noticed anything, this question may prompt them to think through what may have been happening and help the recipient self-realize the impact. This makes your job much easier.

I’d avoid the following –

Did you notice how people felt dejected, and in particular John, after you critiqued his database design?

While that may be indeed what you noticed, it is your own mental model that produced that. Even if your recipient might come to the same conclusion, this closed question places her or him on the defensive and not in a place for self-reflection of their behaviors.

I hope you found this post useful, if you have any tips or tricks you use in giving feedback, feel free to leave a comment or tweet at me!

 

Incorporating Security into User Stories

Violet_ForcefieldOne of the biggest initial resistors I have run across within Federal government employee stakeholders are information security personnel (and their supporting contractors).  This is often because when they learn about how requirements are managed with user stories they don’t see a fit for their requirements; in the Federal space these are guided by FIPS 200 and NIST 800-53 (currently at rev 4). Other writings on the subject do little to help them. Most advocate a separate and distinct type of story such as this paper by SafeCode or relying wholly on Dark or Evil stories written from a point of view of someone trying to gain access to a system, or deny access to a system.

There is no reason software-centric security controls can’t become user stories and/or acceptance criteria to user stories.  This post is going to attempt to show you a bit how to think on this. There is value in using dark stories as well, but I advocate first getting stories that incorporate NIST controls within the backlog.

First up, one must understand that the controls in NIST 800-53 cover a large number of dimensions including physical space control, configuration management, training, etc.  When attempting to convert the controls into user stories and/or acceptance criteria, focus only on the ones that are software-centric.  Controls that deal with authentication, authorization, audit logging, system monitoring, or encryption are great candidates.

Second, per NIST guidance, the organization is expected to establish the baseline needs of applications/systems and then select and tailor the controls needed. This responsibility can fall to the people managing the product features (in Scrum this would be the Product Owner) in concert with IT Security staff. By articulating these as user stories or acceptance criteria to user stories, these now have business value. The person managing what gets done no longer has to make a leap of faith or be told by someone externally that they just have to have it.

IN the following examples, we’re going to follow the Specifications by Example format and use a generics  records review system as an example that places records in a list for authoritative storage (a separate system); it handles Personal Identifiable Information. Let’s start with a story…

User Login Story

As a User Requiring Authentication,
I want to Login to the DataReview application
So that I can review incoming survey data for quality

//Standard Login Scenario
Given the username jsmith // valid userid
When I attempt a login using “nS3cure” // correct password
Then I the main home portal page is displayed for me

Given the username jsmith // valid userid
When I attempt a login using “123” // incorrect password
Then I see the login page again with the statement “Incorrect userid or password” stated along with a count of Login attempts.

Given the username smithj // invalid userid
When I attempt a login using “nS3cure”     //password correctness is immaterial
Then I see the login page again with the statement “Incorrect userid or password” stated along with a count of Login attempts.

// Multiple Login Failure Scenario
Given two failed login attempts and the username jsmith // valid userid – 3 attempts require a lock out for a period of time
When I attempt a login using using “123” // incorrect password
Then I see the login page again with the statement “Third failed login attempt, your IP address has been locked out for 3 hours” // 3 hrs by policy

Given two failed login attempts and the username smithj // invalid userid – 3 attempts require a lock out for a period of time
When I attempt a login using “nS3cure”     //password correctness is immaterial
Then I see the login page again with the statement “Third failed login attempt, your IP address has been locked out for 3 hours” // 3 hrs by policy

Given the IP address 130.3.55.121 is locked and the password lockout timer less than or equal to 3 hours // we’re testing using a static IP
When I attempt a login using any username or passowrd
Then I see the login page again with the statement “This IP address has been locked out.” and the password lockout timer is reset to 3 hours.

There could be numerous other additional acceptance criteria as well (password complexity for example), but at least now one can see how these user stories can articulate some of the NIST requirements (in this case AC-7 Unsuccessful Logon Attempts).

Let’s look at how security controls for auditing significant events might show up as acceptance criteria.  In the following example from our records management system, post QC review, we are adding the person’s record into a queue for inclusion into the authoritative system. It is fundamental that we know when this data is placed in the queue for transmittal. This has been determined to be an auditable event per control AU-2.

Approve Record Story

As a QC,
I want to approve records
So that they can be queued for entry into the official records repository.

//Approval
Given authenticated user jsmith has a valid QC role and bjones submitted the record “Mary Maryland” to jsmith for approval
When I approve the record “Victoria Virginia”
Then I see the message “Victoria Virginia record approved”,  the record is appended to awaiting transmittal queue list, and an entry is made to the security audit log with <date-time>, “jsmith”, “QC”, “approved “Victoria Virginia” // policy requires approvals to official records to be logged

//Disapproval
Given authenticated user jsmith has a valid QC role and bjones submitted the record “Mary Maryland” to jsmith for approval
When I disapprove the record “Mary Maryland”
Then I see the message “Mary Maryland record disapproved and returned to bjones” and  the record is returned as the first item in the review queue for bjones

Here we can see how the record gets logged (one form of auditing) when approved.  Because the record isn’t being readied to transition to the authoritative system when disapproved, it was determined that event wasn’t auditable.

Hopefully, this helps folk understand how NIST 800-53 security controls can be incorporated into user stories. By putting them into this format, the development tem now can develop to them and hook them into acceptance testing via something like Cucumber.

 

The Story of Codemess

It’s that time of the season, so it’s time for a story…eiMAogLin

’Twas the night before review

The team stayed up late
To get all the stories done;
Tasks cleaned off their plate.

The CI server
Pulled all of the code
Mongo, Apache,
and a server named Node.

Each dev checked in their bits
Fast as light
Check the acceptance criteria? Pshaw!
I want to go home tonight.

So assumptions were made
With no consultation
And when the code built successfully,
The team squealed with elation!

But they skipped some tests
That kept showing up red
And just prayed that the demo
Would run and not be dead.

So next day was show time
They filed in with fake smiles
The Scrum Master put on all of her charms
And her witty guiles.

They fired up the screens
And showed all their work
The Product Owner turned red
He knew he was going to feel like a jerk.

He couldn’t accept not one
Not two, three, nor four
All stores had failed
Absolutely no score.

So nothing was right
While their efforts were of heroes
All of their stories
The points completed were zeroes.

A failed Sprint they had
One to be remembered
They should be glad
They had not been dismembered.

How they had worked
Needed serious reflection
But to hell with the retro
On to make this damn correction.

So off the team went
Stuck that they knew right
To code and recode
Many a more sleepless night.

The team talked to no one
Silence fell on them all
The Product Owner was be-puzzled
They never did call.

So with that I must state
Team and Product Owner should be as one
Collaborate more often
More stories will get “done-done”.

Keep to your retros
Use them to explore
The reasons for failure
I deeply ask, no implore!

Then enjoy your holidays
With family and good friends
Use the values and principles
As the means to the ends.

So Merry Christmas; Joyous Mawlid el-Nabi
And Happy Rohatsu and Hanukah
And any other you celebrate
Like Yule, Solstice or Kwanzaa.

Happy Holidays may it be filled with tests of green and zero of red…

Agile Dialogs Recap

This will be a short recap of the Agile Dialogs unconference held yesterday.  We discussed ways of predicting value production with and without estimates.  Over the next few days I’ll blog more of what we uncovered, but this will be a simple post on how the unconference was approached.

We had a good mix of people that were passionate, though no one was at I’d say fully at each end of the spectrum. The big takeaway was that both sides are right in many ways and wrong in many ways.  The idea of not using estimates of time, money, and/or story points can be done and is highly context dependent. As with any approach it may nor may not work in your context; it depends, or YMMV.  The best you can do is try it as an experiment and see whether it works for you.

What we did at Agile Dialogs was –

  • register with one side or another along a continuum (how strong we felt on the issue),
  • post the types of things we estimate,
  • tell our stories of both our successes and failures on both sides – with and without estimates
  • explore our objectives for either using or not using objectives and the techniques we use for each side
  • Explore the assumptions used when using estimates
  • Explore the assumptions used when not using estimates
  • Explore what each side could learn from the other
  • Posted and voted on what could possibly be the next thorny topic we tackle
  • and retrospect on how the Agile Dialogs unconference could be better

Here’s a few teasers of some of the discoveries… I’ll go more in depth on what was discussed in future posts as well as post some proceedings on the Agile Dialogs site.

  • When management or customers are asking for estimates, it is more important to understand their need for it; then more valuable alternatives to fulfill that need may be explored. Estimates may prove best for fulfilling that need though, so don’t force fit an alternative technique.
  • Estimation has become a scapegoat for other dysfunctions within the works system. Removing estimation won’t fix these dysfunctions, but it may help uncover them.  Whether at the end of the day, you remain with or without estimation, if these more fundamental dysfunctions can be fixed, then the work climate will improve.
  • Estimation always exists, but when pursuing a noestimates approach, the nature of the estimation actually changes from cost, time, and/or complexity to value (which is not based on those in most environments).
  • Focusing on understanding time and money estimates tends to introduce longer feedback loops for actual learning. If it is possible (and that is an IF), then removing them can eliminate waste in the work system to that learning.
  • Measurement is important in both approaches; when doing estimates we sometimes get lulled into a false sense of security that good measurement exists, when often it doesn’t.
  • Humans suck at estimation except on conceptually obvious items (obvious equating to the obvious domain in the Cynefin framework); mathematical models (particularly when the underlying assumptions on those models are validated by the team doing the work) can really help produce accurate results in the complicated domain.  The complex domain can be assisted greatly by these mathematical models, but the loop through is validating a hypothesis.
  • Another way to test a hypothesis is to set time or cost box and see if the solution at the end of the box is on track decide whether to spend more, accept as-is, or abandon; think Lean Start-up approach.

I have set-up The #AgileDialogs Daily that curates information from both sides of this thorny topic; other thorny topics will get added as a discussion on them emerges.

What’s This Agile Dialogs Thing Anyway?

If you haven’t caught it, I’m running an unconference called Agile Dialogs; you can find out more about it at http://agiledialogs.org.

So why would I want to take on thorny topics, ones that seem to bring out flamewars? Because the lack of listening to each side as we argue from each other’s sidelines seems an inane way of advancing our craft.  If we want organizations to advance their thinking, we in the community need to advance ours and listen to those with differing opinions. It doesn’t mean we need to agree, but we do need to listen, truly listen to what the other side is saying.  When we decide to challenge the other side, we need to do it in a manner that isn’t trying to cole them into accepting we are right, but to have them think through why they are taking the position they have chosen. We may reaffirm it, but in the process, we will have had them rethink underlying assumptions.

Dialog is about understanding and elevating assumptions so we can find answers to our questions and perhaps a new better way forward.  I know I am a believer in good estimates when they make sense and when they don’t not even bothering with them. But perhaps when I thought they weren’t useful, there was a better way to have made them useful.  I certainly welcome learning that in a manner that doesn’t start out with – hey bud you are wrong. That closes down dialog as that is about winning an argument. Save the arguments for a debate, let’s find out what makes each side tick and see what we can learn.

I hope you will join me!

Demonstrating the INVEST Criteria

potters_gold-2

I’ve been doing some rather “loftier” types of post, let’s return to something a bit more fundamental to (software) product development, user stories and in particular the INVEST acronym as developed by Bill Wake (see INVEST in Good Stories, and SMART Tasks). I was helping a coworker with some good examples of stories to showcase the INVEST criteria and felt this may be a useful post for people.

Let’s start with two formats User Stories may be expressed, we’ll stick with latter:

Who-What-Why

Or more commonly as

As a (role or persona)

I want to (perform some business function)

So that I can (get some business value/rationale)

Usually breakdowns in good user stories fail to articulate one or more of the INVEST criteria. Let’s look at each separately along with some examples.

I = Independent

We want stories to be independent; an independent story should be small vertical slice through most, if not all, of the software stack (UI, business logic, data persistence, etc.). Let’s start with a counter example to help demonstrate this.

As a decision-maker,

I want the data selection table menu to show the latest option results

So that I can determine which one to analyze.

Sounds OK right? Not really, the menu is a UI item. Where is this data going to come from, presumably a database, file, or API. It may get processed in a middle tier to do some filtering or sorting. The UI layer where the menu resides is only one layer; this story would be dependent on other stories in other layers to be able to be implementable. Usually any story that goes into the ‘how’, becomes less independent. Let’s rewrite it to –

As a decision-maker,

I want to view the latest option results

So that I can determine which one to analyze.

Besides appearing simpler, this doesn’t specify the menu, leaving the development team needing to do all the tasks to implement the results. Tasks could be querying the table, apply filter algorithm for outliers, sort from highest to lowest, display as a menu. It also doesn’t lock the team into the how – if the result could also come from an API or web service they can present those as an options to the product owner for selection; same with the menu, perhaps a table would be better.

N = Negotiable

Negotiable means the product owner and development team can make trade-offs on the priority of the story and/or acceptance criteria. Again let’s start with a counter example.

As a survey reviewer

I want to compare multiple respondent data sets

So that I can see if a correlation may exist.

What data sets? What data of the data sets? How is the product owner supposed to negotiate on this? Let’s add some detail –

As a survey reviewer

I want to compare age bracket data to geographic region

So that I can see if particular geographic regions contain particular high levels of a particular age group.

This is more negotiable; why? Suppose there was a second story –

As a survey reviewer

I want to compare income bracket data to geographic region

So that I can see if particular geographic regions contain particular high levels of a particular income.

Now the product owner can negotiate on which one is more important? They could also dig into acceptance criteria and talk about the ages or incomes that make up those brackets or what level of granularity they need to do for the regions. Often non-negotiable stories, ones that seem that MUST be done and can’t be ranked against others that MUST be done also are an indicator they are too big; they encompass too much.

V = Valuable

Another counter example will illustrate a story that doesn’t articulate value…

As a decision-maker,

I want to view the latest results

So that I can see them in order.

Why do I want to see them in order? (It’s presumed the order desired would be acceptance criteria. Better to specify the why, this also usually indicates why not only is the function needed, but why the particular acceptance criteria was chosen. Here is our refined story again –

As a decision-maker,

I want to view the latest results

So that I can determine which one to analyze.

Now we know why we need to do it.

E= Estimable

We don’t care so much about the estimate, which is one reason we use relative estimation based on complexity over trying to nail down an estimate in effort/length of time (hours for either). We care that some amount of certainty in the complexity can be articulated; this gives us a gauge that it is understood well enough to start. The higher the estimate, the less certainty, meaning it is more complex. At some point, this may require splitting into 2 or more stories to reduce complexity.

As a investor,

I want the latest analysis

So that I can decide what to do.

What do we mean by latest analysis? How do we estimate that? And that value statement doesn’t help; what decision are we trying to make – the business function – and why do I want to make it – the why. Here’s a story that may be estimable (providing acceptance criteria can be drawn from this)

As a investor,

I want the latest ROI graph with my minimum threshold shown

So that I can decide whether to continue making this investment.

OK, we want a graph, which we know must draw on data; if the raw data needs to go through calculations, we will need to do that. This threshold, is it entered or stored somewhere? Looks like well need tests to ensure the calculations are done properly. If we need to ensure web accessibility for people with sight disabilities, we may need a textual equivalent. Regardless, even with this uncertainty, being able to see most of the tasks and thinking on their complexity will give me the ability to estimate. Many have found that the estimate becomes pointless once the team actually has confidence they can complete it along with other stories in an iteration; remember this is mostly to describe common understanding. This may take months or even years to get to that point though.

S = Sized properly

Hand-in-hand with estimable, is sizing. If the story is large, really complex, then we need to think about splitting it into smaller independent stories. A good example of a story that is probably too large is the first story that dealt with a survey reviewer. The stories that follow it describing the data sets to compare are smaller and clearer and probably could be successfully implemented within an iteration. Who knows if the first one could? Also, if I couldn’t I get no partial credit for getting some of it done. If I get any small story done, then I can take credit for it.

And lastly, T = Testable

Testable stories are determined by their acceptance criteria. Let’s go to our first good story and fill in some acceptance criteria to see this clearly.

As a decision-maker,

I want to view the latest option results

So that I can determine which one to analyze.

When we turn the card over, we find the…

Acceptance Criteria:

  • Display options as menu choices
  • Display options in descending order from highest to lowest
  • Display results below my threshold in red and bold these
  • Don’t display negative results
  • Option results are calculated by the uncertainty index to the simulation result
  • Return the results in 0.3 of a second

These are easily testable, manually or in an automated fashion. (NOTE: there is a more sophisticated method called Given-When-Then from Specifications by Example by Gojko Adzic that allow these tests to be more easily automated in tools such as Cucumber.)

Using Dollars as a Constraint on a Project

I’ve been planning to write this for awhile, and this seemed to me more important to post after seeing an update from a Kickstarter campaign I am backing.

So I backed a board game, I was particularly interested in that it i intended to be small so I can take it with me almost anywhere I go.  What was amazing to me was how they calculated what they needed for funding.

Before I dive into that, I’ve backed quite a few boardgames on Kickstarter (along with music albums, music gear, and camping gear…) Most Kickstarter projects go in with varying degrees of estimations; one nice thing Kickstarter does is if you don’t reach your funding goal you don’t owe to make anything and the backers keep their money.  If you get funded, your estimates hopefully allow you to produce the game and have at least a small measure of profit. Most projects offer stretch goals that when they are reached, component upgrades and such kick in – these usually have a change in your estimate.

The gentleman that developed Carrier Commander, decided on a price point he wanted to be able to sell the game ($3 as it is a nanogame; I love small games to take with me when I travel). From there he reversed everything into size and weight by calculation based on what would be possible should he hit his stretch goals.

On the campaign page, he reveals the cost breakdown including the “Uh-Oh” zone which is the profit area…

To read up on how he calculated his way into the $3 price point without estimating, see this update:

https://www.kickstarter.com/projects/1078944858/star-patrol-carrier-commander-3-sci-fi-strategy-na/posts/1348731?ref=dash

Should all Kickstarters work this way?  Probably not…  The larger the game, the more the calculations would become overly cumbersome, particular as stretch goals needed to be calculated, so using estimation and factoring in reserve to cover the uncertainty would probably suffice.  In his instance, his upgrades were in cardboard only, so this made it much easier.

So how would this relate to software development? As I wrote in my post “When I Have Skipped Estimates”, one could use a team size as a constraint and then measure throughout.  Once the constraining bottleneck is understood and all worthwhile options for increasing throughput there have been exhausted, you could increase capacity.  This really works well for software maintenance.

One could also use something akin to what this gentleman did for his Kickstarter game; establish a fair market value for the cost of what you are building (i.e. how much is someone willing to pay to have something by a particular point in time).  Once you have this you have both time and budget constraint and now you can see how much that would pay for in terms of people and other infrastructural resource one may need; i.e. what is the capacity it can purchase?  Let’s say we got enough money that it would pay for 7 people for 6 months (+ servers, desktops, software licenses, etc). We can then execute and develop based on that.

One may ask at this point, how do you know if you will make what is needed? You actually don’t. What you do know is that this is what the person or people that set the constraint said would be what they are willing to pay. Like a venture capitalist, they have in their mind, I am willing to risk this amount of money to see if I can get what I want.  Yep, no guarantee. But then, an estimate doesn’t produce one either.

Should you do this under all cases? Absolutely not. In fact, I would say estimation is needed more often than not when deciding to fund a project (or program). And for those cases, we as an industry need to improve in estimation. However, there are cases,where estimation doesn’t necessarily help us. The more novel the project (and thus its approach), the greater the uncertainty and at some point it may be best to establish a cost (and perhaps schedule) constraint and see what you get at the end of that.  Got something valuable? Perhaps continue forward (and perhaps now introduce estimation); what you got isn’t valuable? Then you can use the knowledge you gained to decide to continue or not (and perhaps add in estimation or not).  You can use the knowledge you have to make a decision.

At least those are the cases I have for when I would go a #noestimates route… What are yours?

I’m interested in exploring each side; if this interests you, I hope you will consider joining me at the first Agile Dialogs unconference I am putting together.