Suscheck's Blog

Successive Refinement of Requirement/design

2012-01-26T14:24:00.000-08:00

In agile, requirements are progressively detailed, with the finest details being developed as late as feasible. There are three main reasons for this just in time requirements detailing: no time is wasted on requirements that are possibly not going to be developed, decisions about requirements can take into account lessons learned in prior sprints and the requirements fresh in the mind of the team when they begin developing because the lag time between specification and implementation is short. Enabling flexibility in the requirements backlog and minimizing wasted work are just as important as detailing the requirements.

Design documentation has its highest value in helping work out the details of the software under construction, not as post implementation documentation. As a post-implementation artifact, documentation must be kept up to date with the software which adds to the cost of any software changes. If the documentation is even slightly out of date, the documentation looses credibility – the code becomes the ultimate documentation. Unless the documentation is automatically generated, design documentation is of limited value and should be prioritized low.

The pacesetter?

2011-12-10T14:13:00.000-08:00

Pacesetting is a leadership style based on the premise that the leader’s manner of doing things is best. While the intentions may be noble (getting the project done) it’s a form of ego and can border on recklessness. Often times the individual doesn’t even realize that he/she is exhibiting classic signs of this leadership style.

First and foremost, we must recognize that agile development can provide a wealth of opportunities to act as a pacesetter. Consider the effect of one week iterations: given the right circumstances, at the end of every week there’s an opportunity to be a hero – to ensure that the team makes the weekly commitment goal. Another problem is that immature product owners can take advantage of pacesetters, pressuring them to add little features, and with agile’s emphasis on collaboration, there is often no way of telling (e.g. no documentation and change control) that the pacesetter is allowing micro bursts of scope creep. The technique of pair programming provides another prime opportunity for the pacesetter to be the center of gravity for getting things done, leading (or pushing) the pairing partner. Self selecting stories from the backlog can easily turn into a game where the pacesetter assigns him/herself to an inordinate number of stories early in the sprint – effectively marking many stories “in process”.

Agile development can also be a threat to the pacesetter’s sense of control – which can exaggerate the negative behavior. Agile emphasizes whole team participation, responsibility, and rewards. The pacesetter may feel lost and long to add value as an individual.

Back to product owners

2011-10-26T14:10:00.000-07:00

So what's it take for a product owner to work well?

Observations:
• Technical people (i.e. former or current developers) can make poor product owners as they can tend to focus on the technical rather than business side of the house.
• Some of the best product owners are those that are very close to the customer.
• A manager may be a poor product owner because they tend to see the product in terms of tasks rather than features.
• Rotating a product owner causes quite a bit of churn. Don’t do it.
• Multiple product owners can be a bad idea unless they can collaborate together. Multiple product owners can be just as bad as multiple managers trying to manage one project.
• Product owners must be organized enough so they have stories ready for the sprint planning session.
• Business analysts can make good product owners as can technical sales people and product trainers.
• Look at the values of the agile manifesto and make sure your product owner can buy into them.
• If multiple stakeholders are involved in the product, you need one product owner to represent them. And that one representative must have the authority to make decisions without constant negotiation of the other stakeholders.

Word Cloud generators?

2011-09-26T14:08:00.000-07:00

I had an interesting experience, I created a word cloud of my resume. Have you tried wordclouding unusual items? I've seen it done on code (if you remove the comments). I used wordle. Pretty cool.

Product owners?

2011-08-26T14:02:00.000-07:00

What are some of the things to look for when starting up an agile team and choosing the product owner?

A good product owner must have:

Knowledge

· Knows enough about the product to create and maintain a backlog – can write reasonable requirements and eventually stories.

· Knows enough about the product and it’s context to conveys the vision and goals of the project and each sprint.

· Understands the needs of the customer.

· Knows enough about the technology to make reasonable decisions.

Authority

· Can carry through the result of any tough decisions.

· Owns the product success (or failure), so can prioritize the backlog and eliminate stories if they’re not high value.

· Represents the customer, interfaces and engages the customer.

· Can change the course of the project at the end of every Sprint.

· Can terminate a Sprint if he/she determines such action is required.

· Has the recognition to communicate status externally.

Availability

· Has the time to work on the product backlog, despite other responsibilities.

· Can actively participate in the daily Scrums, Sprint Planning Meetings and Sprint Reviews and Retrospectives.

· Has enough time to quickly respond to questions (that day) and sit with the development team when needed.

· Actively inspects the product progress at the end of every Sprint and has complete authority to accept or reject work done.

Aptitude

· Able to resist the temptation to micromanage.

· Not be afraid to make tough decisions.

· Able to work in a team environment.

· Focused, proactive, and engaged in the product.

· Good negotiator.

· Deeply interested in helping the team be successful.

· A “People Person” with patience.

· Willing to learn and flexible enough to deal with the changes of agile.

Tips for new BAs

2010-08-15T13:00:00.000-07:00

Remember that your business contacts are usually very busy and may not see providing information for project requirements as a priority. Be persistent, but considerate of their situation.

Ask people when the best times to talk to them are and when it is best to leave them alone (when end of month process is going on, for example).
Find out their preferred method of communication. If someone never responds to your e-mails try phone calls or stopping by their desk. If they hate interruptions, schedule time to meet or use e-mail.

If you are not getting adequate time with someone you need to talk to, address the problem as soon as possible. Talk to the person about possible times to meet. Address the issue with the project manager and in your status report.

Target your communication to your audience. Busy executives may not read anything except a single page with bullet points. Others will want to read every detail before signing off. Visual people may understand flow charts better than use case descriptions. Don’t use technical jargon or acronyms that your audience is unlikely to understand.

Since time is usually limited, use an agenda for all meetings and follow up by sending meeting minutes to the team.

Always, always have an agenda for meetings and a set of goals for the meetings.

Mind Puzzles

2010-07-30T13:00:00.000-07:00

Here are some ways to exercise creative thinking. They are separate from eachother. Have fun.

Clear your mind

The idea is to get rid of problems that are keeping you from concentrating on the task at hand.
Take out a piece of paper and quickly write down any issues which come to mind. It doesn’t matter how small the issue is, write it down. Keep writing until there is nothing left to write. Then look at the list and acknowledge that you will deal with these concerns later. Fold the paper up and put it on the corner of your desk for later.

Define your problem

The idea is to come up with different expressions of your problem, leading to a new and unusual solution.
Use an idea quota. Write down 5 different ways to express your problem in 1 sentence.

Repeat at least 3 times.

Why and what ways

The idea is to drive to root cause (why) and back up to potential solutions.

Why do I spend time less time doing this thing that I should?

Why do you want to ...?

Why do you ...?

Why do you ...?

Why ...

Now restate the answers as “In what ways can I ....”

Mind map and negative mind map

The idea is to see the problem from a negative perspective and strengthen the positive.
Do a mind map of the problem.
Now do a mind map of the opposite of the ideas. I.E. opposite of fitness is sloth.

Random words

The idea is to look at the problem from differnt perspectives.

“In what ways can I ________________?”

Choose a random verb.

Explore the relationship between the sentence and your subject and then explore the non-relationship between the sentence and your subject.

Random Number Generators and Slot Machines

2010-07-15T13:00:00.000-07:00

Has this ever happened to you: you're playing your favorite slot machine for nearly two hours, hoping to get that big jackpot but never really winning it. You take a break for lunch and come back an hour later just to see someone else playing your machine hit the big one. Is your first thought, "That's my jackpot! If I had only stayed I would have won it all.” Don't believe it. Slot machines are based on a sequence of pseudo-random numbers and, in a way, the timing of your play.

An slot machine is a computer (Electronic Gaming Machine or EGM actually) and computers can't really create random numbers, but can generate sequences of numbers that are mimic randomness - Pseudo Random Numbers which are widely known as PRNs. The PRNs are exercised with battery of tests run against the output to ensure the numbers are statistically random. The most common algorithm, the linear congruent method (LCM) which generates numbers such that same sequence of numbers won't occur until about 2 billion numbers have been generated. Many EGMs use variations of the LCM that have cycle periods close to the number of molecules in our galaxy! You can't guess the sequence even if you know the algorithm.

As a rule, EGMs generate a random number continuously, not every time you drop in a coin. It's not unusual for EGMs to generate over 1000 numbers every second. Only when you place your bet does the machine capture the next 'random' number. Knowing the algorithm isn't of much help since you'd have to drop your coin into the machine and bet at the exactly right 1/1000th of a second in order to get the number you were counting on.

Once the number is generated, the computer compares the number to a payout chart. All games have a payout table referred to as the PAR (Percentage Average Return) chart. Each EGM has it's own individual PAR chart, usually ranging from 99% to 81%.

Every game (even if they look the same) has a different PAR chart and the chart is usually held as confidential by the casino. The payout rate advertised on the machine or in the casino usually portrays an average of all the games taken together. Since each game is a separate entity with its own random number generator, it is not uncommon for one game to have a payout of say 95% and the one next to it, with the same game title having a payout of 86%.

To further complicate matters, PAR charts are usually different depending on the amount of the bet. Maximum bet has the highest return rate while smaller bets typically have a lower payout rate.

Once the payout (or loss) is determined, the slot machine spins the spinners with a command from the computer to land on a certain display. The spinners really have NOTHING to do with the actual play, it's all handled by a random number generator and a table. Even the 'bump' of the spinners is pre-determined based on the random number and table. Sorry to take the fun out of it.

The bottom line is that gaming is truly random. If you are at the right place at the right time with max bet you too could win a sizable jackpot on an electronic gaming machine. The fun part is the anticipation of the win and the many little wins along the way that make slot gaming fun regardless of whether you win or loose.

How much worth is the man

2010-06-30T11:44:00.000-07:00

Do you put a dollar on the value your epics deliver to the business? If not you should; it will help you determine epics’ prioritization and give the the business owners an idea of value the project is delivering.

Consider this example: your software is used by 75 sales people and your changes save an average of 2 hours a week per person, you save 2 hour * 75 people or 150 hours a week which translates to 7,500 hours a year (50 weeks). That's 3.75 people's time.

If those people have an average salary of $40 an hour, that's a cost savings $300,00 a year (not bad). If on the other hand each person produces $250,000 in new sales over a year (hopefully you expect staff value is more than their salary) you free up the 250K * 3.75 = $937,500. In the one case you save $300,000 by reallocating people and not growing the business, in the other case you can potentially grow the business by nearly a million.

Next time you’re calculating what a feature is ‘worth’, look at not only the cost savings side but the opportunity side - a perspective that many people miss.

Agile Story Examples

2010-05-24T06:55:00.000-07:00

Story Basics

The basic thing about a real story is that it's a metaphor for the work being done. It is not a requirement but a reminder to collaborate about the topic of the story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration. So the story doesn't make you agile, it's the underlying philosophy.

Invest model for good stories

A good story, from our perspective uses the invest model –

Independent – reduced dependencies = easier to plan
Negotiable – details added via collaboration
Valuable – provides value to the customer
Estimable – too big or too vague = not estimable
Small – can be done in less than a week by the team
Testable – good acceptance criteria

But a story is really driven (or perhaps scoped is a better way of saying it) by the acceptance criteria. In other words we try to determine how we'll know when we have satisfied the story before we put any details in it – and we mean actually enough details that we can test the story.

Examples of good stories:

Story:

Generate an Emergency Department Referral

Description:As a provider, I want the option to generate an Emergency Department Referral (EDR) when I close a visit note so that I can share pertinent medical information with other IHE community members.

Acceptance Criteria:
Assumptions:

An IHE Community interface has been configured.
The interface can be configured to send an EDR automatically to the IHE Community.
The interface can be configured to send and EDR to an referral specialist or office staff member.
The interface can be configured to indicate who to send the EDR request.

Acceptance Criteria:
When a user closes a visit note, provide an option on the Visit Checkout screen to generate an EDR. This option will indicate that the provider intends to create an ED Referral.

Story:

Strip special characters from policy fields before creating electronic transmission claim file.

Description:
As a front desk/billing user, I would like to be able to scan insurance cards through OCR and not have to go back and edit certain fields due to dashes in the policy IDs.

In addition, I would also like this information to be formatted correctly for my electronic transmission so that I do not get claim rejections.

Acceptance Criteria:
Provide the ability for dashes to be removed from the member ID and group ID when creating the file for electronic transmission. This process was also necessary by interfacing products to remove dashes from policy IDs to prevent rejections. Investigation may include researching how other products accomplished this task.

Also, users should be able to utilize OCR scanning without having to edit patient information manually (removing dashes).

Story:

Need a way to print multiple patients on a label sheet

Description:
As a System user I would like to be able to print multiple patients on one label sheet so that I don’t have to look at multiple pages.

Acceptance Criteria:
At least 6 patients print on one label sheet.

Critique of bad stories:

Story:

Add capability to select the Welch-Allyn Exercise ECG Test

Description:
This requirement was requested during the W-A certification demo 2/17/09.

***Description doesn’t specify who or why this is important. What needs to be done? Can’t tell.

Acceptance Criteria:
***missing

Story:

Cursor should default in assign to field instead of patient field when creating a new procedure task message in FNC.

***Could be shortened to “Default cursor to assign” The rest can be in the description. Overall this may be TOO small to be a story and could be rolled into another related piece of work.

Description:
As a System user, I would like the cursor to default in the assign to field instead of the patient field when creating a new procedure task message. The patient name is already in the field since I'm creating the message, so I would prefer the cursor to default in the assign to field.

***Could shorten this to:

As a System user, the cursor will default to assign field when creating a new procedure task message so that I can be more efficient.

Acceptance Criteria:

***missing. Can add this:

When creating a new procedure task message, the cursor will default to assign as opposed to patient name.

Demonstration must be to the satisfaction of Dr. Lohindez of Rogue Wave software (he has requested this functionality).

Some Good Resources for Agile

2010-05-17T07:02:00.000-07:00

A few great books:
• Applying User Stories – Mike Cohn
• Agile Estimating and Planning – Mike Cohn
• Collaboration Explained – Jean Tabaka
• Lean Software Development – Mary Poppendieck
• Agile Project Management – Jim Highsmith
• Agile Project Management with Scrum – Ken Schwaber
• Managing Agile Projects – Sanjiv Augustine
• FIT For Developing Software – Rick Mugridge, Ward Cunningham
• Agile and Iterative Development – Craig Larman
• Domain-Driven Design: Tackling Complexity in the Heart of Software – Eric Evans
• Working Effectively with Legacy Code – Michael Feathers
• Refactoring To Patterns – Joshua Kerievsky
• Fearless Change: Patterns for Introducing New Ideas – Linda Rising, Mary Lynn Manns
• Product Development for the Lean Enterprise – Michael Kennedy

Online Resources:
http://www.agilealliance.org/
http://www.theagileblog.net/
http://www.rallydev.com/
http://www.mountaingoatsoftware.com/
http://www.stickyminds.com/

Yahoo! Groups:
scrumdevelopment
agileprojectmanagement
agiledenver
extremeprogramming
agiletesting

New Article Published

2010-05-04T12:01:00.000-07:00

I've just had an article published that compares traditional requirements, use cases, and user stories.

Six Weapons of Influence in action

2010-03-24T05:32:00.000-07:00

The following is an example I created to convince people that retrospectives are useful. I used the six weapons of influence as a guideline.

Recently, team members have questioned the benefit of certain aspects of the agile, specifically retrospectives. [Acknowledge the problem to gain alignment with the audience]

In regards to retrospectives, certainly each of us wants to improve our on the job performance [setting up consistency]. Retrospectives are specifically intended to improve individual and team performance each and every sprint [pointing out the inconsistency of not holding retrospectives]. Numerous studies and experts agree that retrospectives are a potent tool for performance improvement when executed well [Authority or Directed Deference]. Reflecting on how to become more effective and tuning behavior to maximize effectiveness [consistency] is so important that the originators of agile development list it as one of the twelve principles behind the agile manifesto [Authority or Directed Deference].

As a group, we have committed to following agile development through the scrum process [social proof]. Retrospectives are an important part of the process – one that we all need to improve upon in order to better see the benefits [social proof and consistency].

We realize that retrospectives are not easy and take time. It’s no simple task to ferret out good retrospective items and put them in a form that can be actionable [align with audience].

In order to better support retrospectives, upper management will commit to allow time to work on retrospective items during sprints if the retrospective items are written as actionable stories [Reciprocation]. We also commit to providing, upon your request, retrospective coaching for individuals or groups, and will share examples of good and bad retrospective items. In return we ask for your willingness to continue retrospectives and your support in working with us on improving efficiency/quality/delivery [Reciprocation].

The Inverse Peter Principle?

2010-03-07T04:53:00.000-08:00

We all know the developer hero who works for 30 or more hours straight when a crisis comes up and walks away solving the problem. The classic firefighter mentality of software development. But what kind of manager does this hero make?

Star developers often rise to management because of their ability to program under pressure and, in many cases, their software fire fighting ability, not necessarily the ability to plan, track, motivate, and manage a project.

If the corporate culture rewards a hacker mentality - time savings and emergencies over strategy and planning, developers who rise to management may never be exposed to long term thinking and may not even be told that management is all about planning, managing risks, monitoring, and most importantly reflecting on the future. Do star firefighters have the key ability to plan, see strategy, and organize large groups of people - I would say not always.

So what do we do about this problem? How about promoting people to management for their tendency to over design, over plan, and not necessarily just hack? This is an inverse of the peter principle. Imagine programmers who are mediocre by firefighting standards being promoted to management. We might just be better off in the industry.

Then companies could proudly proclaim “we promote the mediocre” – ah, maybe not.

Sorry Spock, logic isn't always the best motivator

2010-01-10T16:11:00.000-08:00

Influence

A big part of my job is to influence people to perform tasks and behave in a particular way that they're not used to; and I often have no direct control over those who I must motivate. Being a bit of an academic, I thought about and subsequently researched the best way to influence the herd of cats to go in the direction I'd like them to.

Logic

As a classically trained software engineer, my first thought was that through brute force logic I could convince even the most stubborn naysayer of anything, as long as the conclusion and reasoning is logical. With a little research, you too can find interesting articles on formal logic and reasoning. But if Dr. Phil asked “how’s that working out for you?” my answer, with a hint of frustration, would have to be “not always very well”. Surprise! People don’t always respond to logic – if so there’d be no smokers, heavy drinkers, or suicide bombers.

Influencing people involves not only logic (what you’re trying to convince people of), but invoking their emotions (how you’re convincing them) and a social aspect of convincing the right people.

Emotion
So how do you get the emotion monster involved? After reading many, many texts on the subject, the best categorization of emotional influence techniques is the six weapons of influence. I’ve used one or more of these weapons in combination with quite a bit of formal logic with success many times, but not always. Dispite the best emotional influence and carefully applied logic, some people just won’t move in the right direction.

Social Pressure
This is where the leader crowd comes in to play - some people need to be lead, either explicitly or implicitly. So you have to convince the formal and informal leaders (the leader crowd) to support your ideas before that herd of cats begins heading in the right direction. To influence the leader crowd, the first step is to identify the right people – something that is situational and beyond what I can blog about today. Do make sure to identify the informal leaders though - they're the people who, when they speak in the meeting, never have to raise their voices because everyone seems to listen. The second step is to use logic, emotion, and social pressure to convince the leader crowd. You’ll find that the lead crowd has its own, smaller leader crowd which in turn has a smaller leader crow and so forth. The deeper you get into the leader crowd, the less prominent the social pressure side of influence becomes. Eventually you’ll get to the leader crowd where you begin to influence without much of the social aspect whatsoever (think Malcom Gladwell’s tipping point). These are the independent leaders, influence them and the rest of the cats herd will be easier to manipulate.

I hope this helps you to look at influence as a bit more than just logic and has inspired you to do a little research on your own.

Personal Kanban Board

2009-12-06T07:26:00.002-08:00

Are you having a hard time with interruptions in your every day work? Do interruptions and priority changes make you feel like you can’t keep everything straight and seem to never get anything done? I know how you feel. I’ve been in that position many times and what I’m discovering is that lean/agile principles can help on a personal, not just a team level. I’ve been using a personal kanban board for a few months now and can say emphatically that it works!

Here’s what I mean by a personal scrum board. I have a whiteboard in my office divided into columns: backlog, staged, in process, ready for review, done. I keep track of all of my work on sticky pads very much in the same way as story cards. I also give each task a priority based on customer value. Work moves from column to column, eventually into the done column. I purposely keep work in process to one or two items and when a higher priority items pops up, it gets moved into the top of the staging column.

All of this seems like simply making a list and executing the list. That’s true, but the real power of the board is the agile processes that I can pull into my personal work. The board gives me plenty of visibility to those who work with me. I also have a morning daily planning session (by myself) before I begin work. I make sure that if anything that doesn’t flow through the board in a couple of days is evaluated to see why is it stopping up the flow. I also keep an impediment list that everyone coming into my office sees – my manager is responsible for helping with the impediment list.

If you’d like to try a personal kanban board, there’s information on the net for determining how kanban works. I’d encourage you to investigate and try it. Corey Ladis has a lot of information on: http://leansoftwareengineering.com/

The genius of story points

2009-12-06T07:26:00.001-08:00

People have a really hard time wrapping their head around the idea that story points are not related directly to time. They are related to velocity and there’s a real genius in this idea. Let me explain.

Let’s say you estimate based on ideal days. The problem is: how many actual days equal an ideal day? If you’re like most managers there’s a one to one correlation, despite any grounding in reality! You’ve got to calibrate the number of ideal days with reality which is what story points tend to do, but in a slightly different manner – via velocity and the abstract number that comes out of points.

Story points are meant to categorize stories by effort and size. Once you’ve initially categorized your work via story points, you pull in a few stories into your first sprint and then sum up the number of points you think you can do. Once the sprint is complete, you see how many story points you’ve actually completed and that becomes your initial velocity. If you are consistent in estimating story points, you can begin to figure out how many story points you can take in based on velocity.I think the reason story points are so fishy to a number of people is that they’re anchored in velocity, which is something that a new, forming team, doesn’t have yet. Once you’ve completed a few sprints, you’ll have a velocity and a set of canonical stories for each group of story points that you can then hang your hat on.

Musicianship and agile development

2009-11-15T07:40:00.000-08:00

People have asked my why I gravitated toward agile development after a long career with heavy control-driven process. (I have experience with RUP and it can be misused just in such a way).

After thinking about it quite a bit, agile collaboration is part of my upbringing, being a musician. I'm not just a musician, but the lowest form of musician - a bass player. I play tuba and bass guitar and it's pretty unusual for a bass player to take the lead - particularly a tuba player. The job of a good bass player is to support the rest of the band by providing a heartbeat and foundation. When playing bass guitar, I've always felt myself more of a percussion player with notes than another type of guitar player. It's better to play one note or rep over and over correctly and on beat than a Vic Wooten style riff that doesn't work.

Musicians, by nature, have to collaborate. They have to support eachother or have a collective train wreck. While there is some ability to grab glory, the point of the music is the product itself, not the spotlight of a solo.

Next time you're thinking of how agile is different, think about musicianship and the mutual support of musicians. It'll change the way you think of the project.

A story point trick

2009-07-17T14:37:00.000-07:00

So, story points are used to judge the complexity and difficulty of a story in relation to other stories, right? Well, I've seen story pointing sessions where the stories all tend to be the same points (13 or so) or the story points are so controversial that a 1/2 point is added to one story and not another.

Here's a trick. After a few sprints, create a spreadsheet of story references, their points, and the sprint in which they were played. Sort the spreadsheet by point, sprint, then reference. Next time you go to a story pointing session hand out the list to the entire team and use this as a reference when someone trys to split hairs with a story. The point of the matter is to keep pointing consistent among the stories, not highly precise.

As time goes on, the team can strip stories from the spreadsheet that no longer seem like good representatives of that size.

This technique works great!

What's the best way to specify requirements?

2009-07-14T05:45:00.000-07:00

Are user stories better than other types of requirements specification?

User stories are narrative texts that focus on the value a user gains from the system. The basic thing about a real user story is that it's a metaphor for the work being done, not a highly documented requirement. The intent is to enhance collaboration about the topic of the user story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration.

We value people over process, remember? Any technique may be flawed, but it’s the individual and team that can make it work or fail . If someone is used to iterative approach I believe they can make the other use cases and user stories work. If someone is steeped in big requirements up front (BRUF) then they will bring that style to user stories and end up with traditional requirements that are termed stories. At the end of the day it’s the individual that’ll make a technique fail or succeed.

As agile coaches and authors, we stress people and the importance of people and the team, but all too often focus on techniques, not the intent of the techniques or the underlying values of the agile manifesto.

So are user stories the best way to document requirements? Yes, if and only if you can foster collaboration. If your writing user stories and not seeing collaboration, the user stories are not helping and you might as well write traditional requirements (or better yet start to emphasize collaboration).

Agile RTP Meeting - and the economy

2009-06-30T05:39:00.001-07:00

I went to the agile RTP meeting yesterday and heard Johanna Rothman talk about agile development. Great talk. Nice to hear someone reinforce the ideals of agile development.

My biggest question is not that it's a tough market, have people lost the courage to stand up to non-agile or ill-conceived management decisions? With the corporate stand being one of "do it or we'll find someone who will" doesn't this make our jobs that much harder? I posed this question to Ms. Rothman and the answer is obviously yes. It was interesting that her answer also included the idea that people are staying at the wrong job longer, rather than chance moving to a new opportunity for which they may be better suited.

Think about that for a moment - not only is the economy putting pressure on people to perform in a manner that may be beyond reason, it's keeping the wrong people in the wrong position. When we have a turnaround in the economy the chickens will come home to roost.

This is a great time for a forward thinking company to bring on the best people and innovate - not just survive. With so many corporations cutting corners and developing products or supporting products in survival mode, those that take advantage now and look toward growth will be richly rewarded when the economy turns around (and it will) and competition is just starting to innovate.

For individuals, now is the time to really dig into what you're doing. If you are in QA, dig into the code and learn to write fixtures, if you're a BA, learn to read the code, if you're a scrum master, you need to wear an architect hat. Now is not the time to simply be a manager - learn something new on the job to enrich your resume.

I've been quoted

2009-06-28T05:05:00.000-07:00

I was interviewed about agile development by Dr. Dobbs a few months back and would like to give you the link:

http://www.ddj.com/architect/216600161

Upcoming Articles

2009-06-28T04:57:00.000-07:00

I've written a pretty comprehensive article about the different type of requirements specifications- agile, traditional, use case - and I'll be publishing this in the near future. Keep an eye out. People have been asking me for this type of information so it's all going to be in one great article!

Greedy Philanthropy

2009-05-14T13:23:00.000-07:00

The other day I experienced an example of greed; not greed for money or posessions, but greed for the opportunity to do good. Let me explain. Our school had a student who would be on his own (without parents) for a number of week due to a family emergency. Some parents in the school took the initiative to start a calendar where people could volunteer for one night to cook a home made dinner for the student. The completed calendar was distributed to all of the families who volunteered and every day was taken by a different family. When our turn came, we were really excited to cook one of our old family recipies. The student came to our house on Thursday and said that he really wasn't hungry because the volunteer family from Monday cooked extra food so that he had enough for the whole week. While the fellow did eat a little bit, our opportunity to participate in a philanthropic community event was pushed aside by the Monday family's overly generous actions.

Have you experienced anything like this? I've seen it over and over in various organizations (especially PTA) where a small percentage of parents volunteer and then are unwilling to share the load - and often complain that nobody is there to help.

It takes a certain amount of maturity to be able to say "yes, I could use some help" rather than "no, I've got it" even when you probably could do it by yourself.

When I go out to lunch with somebody and I want to pay I no longer say "let me get that". I say "please let me have the honor of paying for your meal". It makes people see it as though they are doing you a favor by allowing you to do them a favor, which is really what relationships are all about.

As you're going about your work, look for opportunities for other people to help you and feel connected. It will not only lighten your load, but give others a sense of usefulness.

Kanban article coming up

2009-04-17T05:42:00.001-07:00

Now published - the Kanban article in Dr Dobbs. http://www.ddj.com/architect/218000215

Defer your decisions!

2009-04-15T05:48:00.000-07:00

Are you familiar with the principle of delaying decisions to the last responsible moment (AKA defer commitment)? The idea is to not make a constraining decision until the last possible moment so that information can be gathered up to that point - making a decision early on may seem, to a PMO adherent, like a prudent course, when in fact it is the opposite of what one wants to do.

I've seen, in many cases, where everything should be laid out in detail before a certain amount of work begins. These decisions are made based on perfunctory designs or shallow analysis - not good. When should these decisions be made? Later - when needed.

Story Points

2009-03-05T12:28:00.000-08:00

Hours, story points

Story points are a measure of relativeness and cannot be used right out of the box. They’re typically used in terms of duration and they have to be calibrated over time. The difficulty with story points is that they are put together in terms of numbers and people like to use numbers for statistics.

For example, does it take you more time or less time to drive from Atlanta to Charlotte than to drive from Cleveland OH to Akron, OH - certainly less. Does it take you more time or less time to drive from Seattle to Miami, probably more since it’s a longer distance. Story points are all about putting a stake in the sand and comparing other work to that reference point.

So let’s take example. I’m going to use the scale 1, 2, 3, 5, 8, 13, 20, 40, 80 as my story points for driving – roughly based on the Fibonacci sequence. We’ll call driving from Raleigh to Charlotte a 5. I’ve done that a number of times and know about how long it takes. I picked 5 as a starting point just to get a number in the middle of the pack. The relationship of the numbers is a factor of 2. What this means is that when compared to a 5, a 3 is ½ the duration, an 8 is twice the duration. 13 is twice the duration of 8 and so forth.

So as you estimate, compare everything you can to the base story – in our case driving from Raleigh to Charlotte. When an argument arises about a story being, say, an 8 or a 13, compare the story being estimated to others that have already been completed. Is the story in hand similar to the 13 we did last week or closer to the 8 we did? In the end remember that precision isn’t the goal, consistency is. A story that’s underestimated in the long run will balance another story that was over estimated. If you’re using story points to determine what can be accomplished in two week iterations, chances are you will only make a week’s worth of error.

Now we’ll story point driving from from Emporia KS to Guymon OK, Trinidad CO to Pueblo CO, Rome GA to Arab MS, Cleveland MS to Cleveland OH? Let’s look at google maps and order them by distance and side roads. I’ll just list the starting points: Trinidad, Rome, Raleigh, Emporia, Cleveland. Now we can start to story point. Is the Rome trip ½ the time as the Raleigh trip? Probably so we’ll point it as a 3. Is Trinidad ½ the time as Rome? It’s close but more likely not ½ the time so we’ll point is as 3. Is Emporia twice as long as Raleigh? I think so and that makes the time a point of 8. How about Cleveland? Twice as long as Emporia? Certainly. Even more? Yes, so a 13 doesn’t cut it. Is it as long as a 40 (in other words more than 4 times as long as Emporia)? Perhaps, but not more than that so we’ll estimate at 40.

Notice for story points of 3 I can estimate the duration down to how many in a given day. For story points in the double digits, my estimate is much rougher.

Now how many times can I drive from Raleigh to Charlotte in a day? Probably twice. So my velocity is two 5 point stories in a day = 10 points. Can I drive the Cleveland route in a day? Nope, but maybe in 4 days. Can I drive the Trinidad route in a day? Yes probably about 3 times.

The next step is to go out and do the work for a fixed amount of time. The first iteration of this type of work is going to be a guess. For example, I’d assume we can do all of the trips except Cleveland in a given week. That’s 19 story points.

Stories, use cases, and traditional requirements

2009-03-02T06:19:00.000-08:00

Comparing user stories, use cases, and traditional requirements.

Comparison example
The client has requested the ability to search for providers by provider specialty.

Traditional Style:
The provider search screen shall provide the ability to search for providers by provider specialty.

Use Case Style:
The client selects the provider search screen.
The system retrieves a predefined list of provider specialties and populates the specialty drop down list. The system displays the provider search screen.

The client selects a provider specialty and clicks search.
The system retrieves a list of providers that match the provider specialty search. [Alt 1]
The system displays the provider list result screen with the matching providers. [Alt 2]
End use case

Alt 1: If there are no matches, the system displays an empty provider list results screen with a message: “no matches found”. End use case.

Alt 2: If there are more matches than fit on one screen (currently 15), then the system displays the provider list result screen with 15 matching providers and a ‘next’ button at the bottom of the screen. Refer to “next button pressed” use case.

Story Style:
Story:
Search for providers by provider specialty.

Description:
As a system user, I need the ability to search for providers by specialty so that I can more efficiently refer patients to specialists.

Acceptance criteria:
The provider search screen will have a specialty search box.
The specialty search box will be pre populated by provider specialties (see specialty in the KDB).
Searching via the provider specialty will return a list of matching specialists or a message indicating that there are no matches.

Good agile stories

2009-02-27T10:51:00.000-08:00

So what is a good story? I’ve been asked that frequently as of late.

The basic thing about a real story is that it's a metaphor for the work being done. It is not a requirement but a reminder to collaborate about the topic of the story - in other words in agile development (good agile at least), the documentation is secondary to the collaboration. So the story doesn't make you agile, it's the underlying philosophy.

A good story, from our perspective uses the invest model –
Independent – reduced dependencies = easier to plan
Negotiable – details added via collaboration
Valuable – provides value to the customer
Estimable – too big or too vague = not estimable
Small – can be done in less than a week by the team
Testable – good acceptance criteria

But a story is really driven by the acceptance criteria. In other words we try to determine how we'll know when we have satisfied the story before we put any details in it – and we mean actually enough details that we can test the story.

I'd be glad to speak with you in on the phone or via email. Part of my job as agile coach is (surprisingly) coaching agile teams.

Our stories have 3 parts, the title, the description and the acceptance criteria. The description is the only part that can be explained as a reasonable template.

Start by writing the description. It should be long enough to allow people on the team can differentiate it from other stories but short enough to fit on a 3” X 5 “ sticky card when written with a marker. Rule of thumb is that a description should be less than 10 words.

Now write the description. You can use the template below.
As a [user role] I want to [goal] so I can [reason].

Using the description, write acceptance criteria. This is the critical piece of the story. Ask the question “how will I know I’ve satisfied the goal and supported the reason” or “how will I know I’ve done that?”

I'll blog another time with examples.

Metrics Kanban versus scrum

2009-02-06T08:22:00.000-08:00

I've analyzed my Scrum productivity and compared it to Kanban. Kanban is over three time more productive from my experience.

Agile 2009

2009-01-23T10:32:00.000-08:00

I've just posted my second session on agile 2009. The first one - experiences in moving from scrum to kanban looks like it will be accepted. The second is a workshop on finding possible solutions to the big problems in agile management.

Agile isn’t free; it comes with new responsibilities, ways of working, and a fundamental shift in principles.Certain legacy procedures and artifacts fall outside of agile, yet interface with the project in such a way as to make the iterative nature of agile development challenging – these are the agile big rocks.

What do you think are the agile big rocks? My candidate list is:

Performance evaluation of agile personnel – how do you motivate the team and the individual?
Agile software development within a waterfall business – how do you do small iterations when the business wants analysis, design, code, and test?
Agile PMO – Can the PMO track agile like a traditional project?
Scrum failure points – Surely Scrum is not perfect. How can you recognize and avoid failure points?
Backlog grooming pain points and resolutions.
Agile forecasting via metrics – how do you plan when you really don’t know what you’re making?

Anything you think should be added?

Skype and Twitter as an agile communication device

2009-01-13T12:36:00.000-08:00

I've been using Skype for quite a while now as a way to communicate in an agile environment. It's pretty good for communicating but I've also found that Skype tends to limit face to face communication. Many times I've Skyped the person right next to me or at the next table just because I'm too lazy to get up and talk or I didn't want to disturb the person when they're listening to music.

I've also found that twitter may be a way to say what you're working on but again, it can limit true collaboration. People tend to rely on the technology. It's a psychology thing - developers tend to be introverted and comfortable with technology (a generalization).

So what do we do? Hold meetings (no)? Get rid of Skype (no)? I'd suggest that we slay the dragon by specifically pointing out that the tool can be a problem for face to face collaboration. Being explicit about the problem can keep people on the striaght and narrow. Face to face collaboration is certainly the highest bandwidth for communication. When you find yourself using Skype too much - pinch yourself and vow not to do that again.

Is scrum perfect?

2009-01-12T06:19:00.001-08:00

In answer to the above question: no, of course not. But is Scrum beyond reproach and criticism? Again I hope not. Scrum is great, and it is a great starting point for many projects that are beginning their agile journey. But Scrum is not the pantheon of perfection. It can be improved upon, particularly if one looks into the principles of lean.

Scrum is not totally lean (of course). We can look at Scrum with a few questions:

Why do we have 2 week sprints? Isn’t that an artificial and therefore wasteful limit that batches up work?
Why do we have 7 people on the team? Can we have less (or more) and make sure everyone is engaged appropriately?
Why do we demo at the end of a sprint and not when the story is complete? Doesn’t this sound like batching work?
Why do we estimate story points in an estimation session? Some of those stories we may not played because of reprioritization?
Shouldn’t estimates be done ONLY by those working on a story? Having people that don’t work on the story estimate seems like a handoff situation.
Why do we work on several stories during a sprint? Can we just work on one and therefore reduce inventories of work?

I believe, that by posing these questions to the Scrum process, one can improve the overall process and work toward a better Scrum.

Do Fish Burp??

2009-01-09T11:44:00.001-08:00

I've decided to keep my blogs lighter, so here goes...

Do fish burp? I know, fish don't swallow air so they don't really burp from that, but most burping really is caused by the process of digestion - the enzymes, and bacteria in your body that give off air when digesting. I tried to google this but couldn't find the answer. Guess I'll be watching my aquarium more carefully.

Lean Software Development - Experiences

2008-09-29T12:24:00.000-07:00

Over the next few days I'm going to post information on experiences with lean software development.

I find it surprising that people actually believe Scrum can work without Lean. LSD helps to organize the backlog, figure out what to do during the sprint, and gets the business on board.

The principles of LSD are most important. Principles drive the practice which drives the technique. Most people concentrate on the techniques, but before you look at techniques, you should ask why (and more questions). Why use these techniques, why do they work, why should I change them. Going back to the principles will guide you when the work at hand can't be boiler plated into a technique. For example if one of your principles is that honesty is the best policy, when your wife asks if her pants make her look fat, you should tell the truth - not doing so would violate your principle in favor of 'say what doesn't rock the boat'.

The LSD principles are:
Optimize the Whole
Eliminate Waste
Build Quality In
Deliver Fast
Defer Commitment
Create Knowledge
Respect People

Over the next few days I'll go into each.

My Presentations at Agile 2008

2008-09-26T12:41:00.000-07:00

My game presentation was spectacular. The participants asked a lot of participation and a number of questions related to the game. In fact some of the people were going to use this game at Nokia. Others suggested that is would create an interesting experiment in group communications. Take away is that I’ll probably play the game in the following months.

Agile 2008

2008-09-26T12:35:00.000-07:00

Trip report from Agile 2008
Trip Date:
August 3, 2008 through August 8, 2008 in Toronto Canada.

Overview:
The majority of the sessions were in workshop format. I.E. the instructor would lecture for the first part of the session, the tables would break into teams and work an exercise, then the instructor would debrief the teams, bringing home some of the points of the lecture. While this worked in some instances, some of the sessions provided very little new information as the exercises were necessarily simple. Most of the sessions that I attended were related to team work and personal interaction rather than technology.

Takeaways
• Other sciences have potential contributions to agile development.
• Over coaching dilutes influence.
• People matters are of primary concern in Agile development and teams must focus on problems at hand.

Agile 2008 takeaways

2008-09-26T12:30:00.000-07:00

I attended Agile 2008 in Toronto this year - August 3, 2008 through August 8, 2008.

Toronto - not a bad city at all. Agile 2008 was a good presentation with a bit too many sessions - 500 over the course of 5 days.

The majority of the sessions were in workshop format. I.E. the instructor would lecture for the first part of the session, the tables would break into teams and work an exercise, then the instructor would debrief the teams, bringing home some of the points of the lecture. While this worked in some instances, some of the sessions provided very little new information as the exercises were necessarily simple. Most of the sessions that I attended were related to team work and personal interaction rather than technology.

Takeaways

Other sciences have potential contributions to agile development.
Over coaching dilutes influence.
People matters are of primary concern in Agile development and teams must focus on problems at hand.