John Hines' Software Process Blog

A blog on Agile software development and Scrum

  Home  |   Contact  |   Syndication    |   Login
  39 Posts | 6 Stories | 42 Comments | 0 Trackbacks

News

The information in this weblog is provided “AS IS” with no warranties, and confers no rights.

This weblog does not represent the thoughts, intentions, plans or strategies of my employer. It is solely my opinion.

To err is human, to forgive is divine.

Tag Cloud


Archives

Post Categories

agile

Thursday, June 26, 2014 #

Mike Cohn has an interesting article on story points, a constant point of contention (no pun intended) on many Agile teams.
 
http://www.scrumalliance.org/community/spotlight/mike-cohn/june-2014/how-many-hours-is-a-story-point-worth
 
"The relationship between points and hours is a distribution. One point equals a distribution with a mean of x and some standard deviation. The same is true, as well, for two-point stories, and so on. While there might be some overlap in elapsed time between 1 and 2 point stories (some one-point stories might turn out to be bigger than the team thought; some two-point stories end up being smaller), or between 2 and 3-point stories, there will rarely be any overlap between a 1-point story and, say, a 13-point story in terms of actual elapsed time."

My team had great success estimating one story point to equal one day (8 billable hours) of work.  Any stories greater than five points, i.e. one week, were split into smaller stories.  After attrition whittled us down to three people we still had consistent and accurate estimates for our work.

And here's the thing - the three of us consistently accomplished 40 story points every two weeks.  That's 10 points "more" than the three of us should have been doing if our estimates were accurate.  What I loved about Scrum was that, while associating story points with actual work implied a measurement of output or productivity, in reality it was just a step toward getting us to estimate more accurately.  In other words we weren't consistently over-achieving, we were consistently over-estimating.  Rather than tweak story size or drill the team to be more in-line with reality we simply acknowledged that our sprint velocity was 40 points and used that to the best of our ability for as long as we could.  The main benefit was schedule predictability and the 5 story point rule which ensured that no one bit off more than they could chew.

I enjoy the discussion on story point sizing.  It's a completely relative and subjective way of quantifying amounts of work to be done.  Like Mike says, points vary from team to team.  Rooting story points in reality helped to get us started, but our agility came from accepting that our estimates didn't quite match reality. 

Tuesday, May 13, 2014 #

"I got involved with Extreme Programming in 2000. Loved it. Best thing since sliced bread, yadda yadda. I was completely spoiled for other kinds of work.

 

So when that contract ended, I went looking for other opportunities to do XP. But guess what? In 2001, there weren't any. So I started teaching people how to do it. Bam! I'm a consultant.

 

Several lean years later (I don't mean Lean, I mean ramen), I'm figuring out this consulting thing. I've got a network, I've got business entity, people actually call me, and oh, oh, and I make a real damn difference.

 

Then Agile starts getting really popular. Certification starts picking up. Scrum's the new hotness, XP's too "unrealistic." I start noticing some of my friends in the biz are dropping out, going back to start companies or lead teams or something real. But I stick with it. I'm thinking, "Sure, there's some bottom feeders creeping in, but Agile's still based on a core of people who really care about doing good work. Besides, if we all leave, what will keep Agile on track?"

 

It gets worse. Now I'm noticing that there are certain clients that simply won't be successful. I can tell in a phone screen. And it's not Scrum's fault, or certification, or anything. It's the clients. They want easy. I start getting picky, turning them down, refusing to do lucrative but ineffective short-term training."

 

Read the rest at http://www.jamesshore.com/Blog/Lament-of-the-Agile-Practitioner.htmlv


Tuesday, December 25, 2012 #

Problem: Dropbox recently stopped working on my Fedora 17 laptop.  Launching it from the Activities menu didn't start the process, and running /usr/bin/dropbox resulted in the following error:

$ /usr/bin/dropbox start
Starting Dropbox...Traceback (most recent call last):
  File "/usr/bin/dropbox", line 1360, in <module>
    ret = main(sys.argv)
  File "/usr/bin/dropbox", line 1349, in main
    result = commands[argv[i]](argv[i+1:])
  File "/usr/bin/dropbox", line 1220, in start
    if not start_dropbox():
  File "/usr/bin/dropbox", line 707, in start_dropbox
    stderr=sys.stderr, stdout=f, close_fds=True)
  File "/usr/lib64/python2.7/subprocess.py", line 679, in __init__
    errread, errwrite)
  File "/usr/lib64/python2.7/subprocess.py", line 1249, in _execute_child
    raise child_exception
OSError: [Errno 8] Exec format error

Solution: Deleting ~/.dropbox* causes dropbox to prompt to re-install, fixing the issue for me.

$ rm -rf ~/.dropbox*
$ /usr/bin/dropbox start
Starting Dropbox...
The Dropbox daemon is not installed!
Run "dropbox start -i" to install the daemon
$ /usr/bin/dropbox start -i
Starting Dropbox...Done!

You'll then be guided through the dropbox re-install and asked to merge with your current dropbox folder.  Choose to merge.

Process: Google didn't help except show a bug or two filed against Ubuntu with this error.  Errors in subprocess.py generally indicate a problem with the values being passed in, and looking at /usr/bin/dropbox it showed the following on line 702:

db_path = os.path.expanduser(u"~/.dropbox-dist/dropboxd").encode(sys.getfilesystemencoding())

Assuming this was the problem, and knowing that a dropbox re-install is easy, I deleted all dropbox directories in my home folder.  I'm not subtle enough to delete only the ~/.dropbox-dist directory but I'll try that next time.


Monday, April 16, 2012 #

From:   Scott F 
----------------------------------------------------

A great team is NOT one that picks up Agile and runs with it.  It is a team that delivers high quality solutions.  Full Stop.

More over, the differencd between teams is not (myhtical) Water Fall vs Agile.  It is anarchic development vs controlled development

Source: http://geekswithblogs.net/jkhines/archive/2011/12/28/why-agile-fails.aspx#612084

Saturday, January 7, 2012 #

Software Engineering is the rare field that produces a product that is never consumed nor decays.  A working piece of software will last forever as long as there is functioning hardware on which to run it.  I once attended a class where a student honestly said that the act of writing software made him feel "immortal".

But most programs (thankfully) don't last forever.  Why?  Because their quality is so poor.  Businesses often treat software like a disposable product because the act of maintaining it is so expensive.  In other words, it's more cost-effective to write new code than to refactor existing code.  We spend our time fixing bugs, bolting new features on top of a bad design, or starting from scratch instead of refactoring existing code into something new.  But...why?

Simply put, my experience has shown me that most bad code is a result of bad engineering.  Many Computer Science graduates haven't been taught good design skills.  Many Software Engineers have spent their careers as Software Maintainers, spending little to no time writing new code.  And managers are unaware that designing new software requires different skills than maintaining it, promoting Software Maintainers to lead the creation of new products, continuing the cycle.

Software Engineering fundamentals are instrumental in fixing the "bad foundation" problem.  It's my goal to share just a few links that I've found useful.

Class Design
  • The Abbott technique (alternate link) is a method from 1983 that famously claims you can parse an English description of a problem statement into a working piece of software.  While it's a stretch to say you can apply rules to get a complete program, you can definitely get an idea of what your classes and many of their members and methods should be.  Perform a web search for "Abbott Textual Analysis" for more guidance on using this technique.
  • CRC Cards are a great next step once you've defined your initial classes.  This will help build out how your classes will interact and exactly what their structure will be.  Best of all, it's an iterative and collaborative process that you can use to get more and more granular.  See the "Reflections on CRC Cards" whitepaper for more guidance on using this technique.
Unified Modeling Language
OK, UML, was way oversold in the '90s.  I know.  It was that decade's Abbott technique - draw a model, get a working program.  It didn't work.  But that doesn't prevent the fact that UML is the standard for describing software composition and behavior.  At the very least, learn these two UML diagrams.
  • UML Class diagram - describes the structure of a class and its relationship to other classes.  Just knowing the difference between a solid line and a dashed line can get you pretty far.
  • UML Sequence diagram - describes the interaction between classes or objects.  This is your, "for example" diagram that goes hand-in-hand with describing how the components in the class diagram fit together.

There are a lot of tools, both commercial and open source, for creating UML diagrams.  I found that with some initial effort I liked Visio 2010 the best.  But only after installing these invaluable, free UML 2.2 stencils for Visio.


Design Patterns
With class design and documentation under your belt you can focus on true Object Oriented techniques.  There are some resources I recommend on the subject:
  • Head First Design Patterns - is a fun way to get your feet wet with design patterns.  Some patterns are covered better than others (I don't like how they lump all of the Factory patterns together), but by the end of the book you'll understand the power of polymorphism and why we rely on aggregation over inheritance in 21st century software development.
  • The Gang of Four (GoF) Book - is the original design pattern book.  Don't be intimidated by its academic tone, it's actually pretty easy to understand.  Some of the patterns aren't heavily used and some of the examples are in SmallTalk.  Still, everyone whose job title says Software Engineer should own and have read this book.
  • For .NET developers, I really like dofactory's site on .NET Design Patterns in C# and VB.NET.  At the very least, I like how their diagrams are actual UML 2.0 instead of the GoF's proto-UML diagrams.
  • For the ubiquitous yet ethereal Model View Controller (MVC) compound design pattern, I like the MVC description on Ward Cunningham's C2 site.  If for nothing than this - The best rubric ever: "We need SMART Models, THIN Controllers, and DUMB Views"

If you adopt the techniques referenced here on a daily basis you can be sure that, even if your software doesn't live forever, you'll have less work to do in the future.  I can tell you that software I've written using these techniques (and more, such as SOA) have scaled into the millions of objects with no need for extra maintenance or rework.  And I'd rather be the kind of Software Engineer that spends my time rewriting other people's code rather than having teams of people rewriting mine.

Technorati tags: Software Engineering Software Engineering Fundamentals


Wednesday, December 28, 2011 #

It's after midnight and I'm resting after a long vacation day with the family.  What am I thinking about?  Scrum, naturally.

What I'm thinking about is this: Why don't Agile practices work on some teams?  Why do some teams pick up Agile and run with it, and others either fail to pick it up or actively fight against it?

It's taken me about two years to come up with the words to summarize my conclusion, which is stated in the introduction to many books on Agile and Scrum: Agile practices are what great teams do naturally.

"So, wait," you might think, "you're saying that if my team isn't Agile, or has struggled to adopt Scrum, then my team isn't great?"  As compassionately as I can say this, my honest answer is "Yes."  It's not that your team is bad - far from it.  It's that your team isn't great.  Because if your team, or my team, was great, we would have picked up Agile and run with it.  No matter what the marketing literature tells you, Agile practices do not make great teams.  It is merely a reflection of them.

Does that mean you shouldn't try?  Absolutely not.  I'll bet 80% of the teams who try Scrum and end up keeping "Scrum but..." get value simply out of the fact that they plan and track their work more frequently.  The problem is that I've been frustrated because Agile practices don't make mediocre teams great.  This may be the most obvious thing in the world, but mediocre teams don't want to be great.  They want to be mediocre, in other words, they want to work the way they always have.

So if you are a frustrated Agile evangelist you have my sympathy.  And here's my personal advice: Go find that great team.  Do everything you can to be a great individual.  Strengthen your engineering skills as much as you can.  Be precise and disciplined.  Earn the respect of your peers through flawless execution and excellent communication.  Because if you're taking the time to read this then I assume you want to be great.  And a great individual on a mediocre team still makes for a mediocre team.  Go help make some amazing thing.

Technorati tags: Agile Scrum

Friday, April 1, 2011 #

Lately I've been pretty critical of the Scrum process, primarily for not containing fail-safes for when things start to go wrong.  I spoke with some pretty passionate Scrum Masters who told me, "Don't blame Scrum for a team's failure to adopt it."  And I've reached the point where I agree.

For any team considering Scrum I have this advice: If you are afraid of Extreme Programming understand you'll get limited benefits from adopting Scrum.  You may get to a point where you work is visible and tracked and possibly even predictable.  But you'll lose out on so much more.  Like safeguarding your predictability becuase you're missing  the increased quality XP brings, or having silo'd technology owners due to lack of collaboration, or inviting inevitable communications issues.

I'd like to see the Scrum Alliance promote both XP and Scrum - and preferably XP first.  Because without those developer disciplines the software engineers on the team won't understand what Scrum is all about.  And, in my opinion, Scrum does a pretty poor job of explaning exactly what it is and exactly what its benefits are.

Many large-scale software development environments are adopting Scrum but are not close to adopting Extreme Programming principles.  Career cube-dwellers tend to like their silos.  But without the engineering piece Scrum will remain a Project Management discipline.  And it will never be a path to enterprise agility.

My personal focus will be strengthening the Agile principles in my own development work and in those around me:

  • Pair programming
  • Test-driven development
  • Continuous integration
  • Refactoring
  • Technical debt management
  • Automated testing
  • Acceptance testing
  • Exploratory testing

Once those fundamentals form the foundation of a team Scrum can be added as nearly an afterthought.

Technorati tags: Agile Scrum


Wednesday, February 9, 2011 #

Working in an enterprise environment is a unique challenge.  There's a lot more to software development than developing software.  A project lead or Scrum Master has to manage personalities and intra-team politics, has to manage accomplishing the task at hand while creating the opportunities and a reputation for handling desirable future work, has to create a competent, happy team that actually delivers while being careful not to burn bridges or hurt feelings outside the team.  Which makes me feel surprised to read advice like:

" The enterprise should figure out what is likely to work best for itself and try to use it."
- Ken Schwaber, The Enterprise and Scrum.

Most large enterprises are fundamentally unable to be self-reflective.  It's like asking a Roman gladiator if he'd like to carve out a little space in the arena for some silent meditation.  It is an open question as to how compatible Scrum is with the top-down hierarchy of life in a large organization.  Specifically, manufacturing-mindset, fixed-release, harmony-valuing large organizations.  It's become clear why Agile can be a better fit for smaller companies without much organizational inertia.

A developer, team, organization, or enterprise can be Agile without using Scrum.  But it isn't obvious what process would be the best fit, in general, for an enterprise that wants to become Agile.  It's possible one should read more than just the introduction to Ken's book.

I do feel prepared to answer some of the questions asked in a previous post:

  • How can Agile practices (including but not limited to Scrum) be adopted in situations where the highest-placed managers in a company demand software within extremely aggressive deadlines?

    Answer: In a very limited capacity at the individual level.  The situation here is that the senior management of this company values any software release more than it values developer well-being, end-user experience, or software quality.  Only if the developing organization is given an immediate refactoring opportunity does this sort of development make sense to a person who values sustainable software.
     
  • How can Agile practices be adopted by teams that do not perform a continuous cycle of new development, such as those whose sole purpose is to reproduce and debug customer issues?

    Answer: It depends.  Scrum is not well suited for unpredictable work.  While you can easily adopt XP practices for bug fixing, the project-management aspects of Scrum require some predictability.  The question here was meant for those who want to apply Scrum to non-development teams.  In some cases it works, in others it does not.


  • How can a team measure if its development efforts are both Agile and employ sound engineering practices?

    Answer: These should be measured independently.  The Agile Principles are a terrific way to measure if a software team is Agile.  Sound engineering practices are those practices which help developers meet the Agile Principles.  Scrum can be mistakenly applied as an engineering practice when it is essentially a project management practice.  In comparison, XP and Lean are examples of sound software engineering practices.


  • How can Agile be explained in an accurate way that describes its benefits to sceptical developers and/or revenue-focused non-developers?

    Answer: Agile techniques will result in higher-quality, lower-cost software development.  This comes primarily from finding defects earlier in the development cycle.  If there are individual developers who do not want to collaborate, write unit tests, or refactor, then these are simply developers who are either working in an area where adding these techniques will not add value (i.e. they are an expert) or they are a developer who is satisfied with the status quo.  In the first case they should be left alone.  In the second case, the results of Agile should be demonstrated by other developers who are willing to receive recognition for their efforts.

It all comes down to individuals, doesn't it?  If you're working in an organization whose Agile adoption consists exclusively of Scrum, consider ways to form individual Agile teams to demonstrate its benefits.  These can be virtual teams that span people across org-chart boundaries.  Once you can measure real value, whether it's Scrum, Lean, or something else, people will follow.  Even the curmudgeons.

Technorati tags: Agile Scrum


Saturday, February 5, 2011 #

Bright Green Projects have an admittedly older blog post entitled Review of Agile Project Management Software | Scrum Kanban Methodology. Since I haven't had time to review Scrum project management tools in quite awhile, it was nice to find a write-up that's as succinct as this one.

The thing I like the best about Bright Green's site, besides the product, is the vocabulary they use to describe Agile software development. For example, they couple Scrum with the development methodology they're using (Lean Kanban). Many organisations simply say they're using Scrum, which itself doesn't prescribe any engineering practices. It would add some clarity for teams to adopt the Scrum-Method terminology. At least then you could know if you're walking into a Scrum-Chaos situation.

Technorati tags: Scrum Scrum Tools


Friday, January 21, 2011 #

There is a growing consensus that the Scrum community should do a better job of promoting Agile engineering practices along with the project-level guidance provided by the Scrum process.  I agree.

But I feel cautious about a debate that seems based on the assumption that any Agile technique is the de-facto standard for developing software.  It's true that Agile has been around for over a decade, but its adoption isn't a given. Many development teams have a fundamental misunderstanding of what Scrum is and what it accomplishes.  There is a majority of developers openly scornful of Test Driven Development. Both "code and test" and Waterfall software development lifecycles are alive and well in the software industry.  Which leads to the questions:

  • How can Agile practices (including but not limited to Scrum) be adopted in situations where the highest-placed managers in a company demand software within extremely aggressive deadlines?
  • How can Agile practices be adopted by teams that do not perform a continuous cycle of new development, such as those whose sole purpose is to reproduce and debug customer issues?

Many software engineers think of software as something that must stand the test of time in terms of performance, scalability, and maintainability.   Business personnel seem to think that software is a disposable commodity meant to generate revenue for a period of time and then be replaced.  It explains the unrealistic deadlines, the emphasis on developer specialization, and the lack of emphasis on collaboration, cross-training, and many Agile tenets.

Developers who excel in this kind of environment seem to feel that Agile methods are for intranet software (software used within a company), while "real" software - revenue-generating customer-oriented software - is something that groups of experts produce as quickly as possible before moving on to the next revenue-generating activity.

Agile cannot become a practice of the majority of software developers until it can convincingly dissuade people from the "disposable software" mindset.  As practicioners we all know that disposable software is a fallacy, that maintenance is a large but avoidable cost, and that reuse is nonexistent for hastily produced products.  But by promoting Agile or Scrum as an efficiency technique, both lose persuasive force when the efficiency doesn't materialize.  Misrepresenting Agile will be the primary reason its adoption loses momentum.

So I'll end with a two final questions:

  • How can a team measure if its development efforts are both Agile and employ sound engineering practices?
  • How can Agile be explained in an accurate way that describes its benefits to sceptical developers and/or revenue-focused non-developers?

It's my hope to come up with some attempts at answers for these questions, but I'd love to know if anyone already has the answers.

Technorati tags: Agile Scrum


Monday, January 17, 2011 #

It's been interesting for me to dive a little deeper into Scrum after realizing how fragile its adoption can be.  I've been particularly impressed with James Shore's essay "Kaizen and Kaikaku" and the Net Objectives post "There are Better Alternatives to Scrum" by Alan Shalloway.  The bottom line: You can't execute Scrum well without being Agile.

Personally, I'm the rare developer who has an interest in project management.  I think the methodology to deliver software is interesting, and that there are many roles whose jobs exist to make software development easier.  As a project lead I've seen Scrum deliver for disciplined, highly motivated teams with solid engineering practices.  It definitely made my job an order of magnitude easier.  As a developer I've experienced huge rewards from having a well-defined pipeline of tasks that were consistently delivered with high quality in short iterations.  In both of these cases Scrum was an addition to a fundamentally solid process and a huge benefit to the team.

The question I'm now facing is how Scrum fits into organizations without solid engineering practices.  The trend that concerns me is one of Scrum being mandated as the single development process across teams where it may not apply.  And we have to realize that Scurm itself isn't even a development process.  This is what worries me the most - the assumption that Scrum on its own increases developer efficiency when it is essentially an exercise in project management.

Jim's essay quotes Tobias Mayer writing, "Scrum is a framework for surfacing organizational dysfunction."  I'm unsure whether a Vice President of Software Development wants to hear that, reality nonwithstanding.  Our Scrum adoption has surfaced a great deal of dysfunction, but I feel the original assumption was that we would experience increased efficiency.  It's starting to feel like a blended approach - Agile/XP techniques for developers, Scrum for project managers - may be a better fit.  Or at least, a better way of framing the conversation.


The blended approach.

Technorati tags: Agile Scrum


Thursday, January 6, 2011 #

I am in the midst of witnessing a variety of teams moving away from Scrum. Some of them are doing things like replacing Scrum terms with more commonly understood terminology. Mainly they have gone back to using industry standard terms and more traditional processes like the RAPID decision making process. For example:

  • Scrum Master becomes Project Lead.
  • Scrum Team becomes Project Team.
  • Product Owner becomes Stakeholders.

I'm actually quite sad to see this happening, but I understand that Scrum is a radical change for most organizations. Teams are slowly but surely moving away from Scrum to a process that non-software engineers can understand and follow. Some could never secure the education or personnel (like a Product Owner) to get the whole team engaged. And many people with decision-making authority do not see the value in Scrum besides task planning and tracking.

You see, Scrum cannot be mandated. No one can force a team to be Agile, collaborate, continuously improve, and self-reflect. Agile adoptions must start from a position of mutual trust and willingness to change. And most software teams aren't like that. Here is my personal epiphany from over a year of attempting to promote Agile on a small development team: The desire to embrace Agile methodologies must come from each and every member of the team. If this desire does not exist - if the team is satisfied with its current process, if the team is not motivated to improve, or if the team is afraid of change - the actual demonstration of all the benefits prescribed by Agile and Scrum will take years.

I've read some blog posts lately that criticise Scrum for demanding "Big Change Up Front." One's opinion of software methodologies boils down to one's perspective. If you see modern software development as successful, you will advocate for small, incremental changes to how it is done. If you see it as broken, you'll be much more motivated to take risks and try something different. So my question to you is this - is modern software development healthy or in need of dramatic improvement?

I can tell you from personal experience that any project that requires exploration, planning, development, stabilisation, and deployment is hard. Trying to make that process better with only a slightly modified approach is a mistake. You will become completely dependent upon the skillset of your team (the only variable you can change). But the difficulty of planned work isn't one of skill. It isn't until you solve the fundamental challenges of communication, collaboration, quality, and efficiency that skill even comes into play. So I advocate for Big Change Up Front. And I advocate for it to happen often until those involved can say, from experience, that it is no longer needed.

I hope every engineer has the opportunity to see the benefits of Agile and Scrum on a highly functional team. I'll close with more key learnings that can help with a Scrum adoption:

  1. Your leaders must understand Scrum. They must understand software development, its inherent difficulties, and how Scrum helps. If you attempt to adopt Scrum before the understanding is there, your leaders will apply traditional solutions to your problems - often creating more problems.
  2. Success should be measured by quality, not revenue. Namely, the value of software to an organization is the revenue it generates minus ongoing support costs. You should identify quality-based metrics that show the effect Agile techniques have on your software.
  3. Motivation is everything. I finally understand why so many Agile advocates say you that if you are not on a team using Agile, you should leave and find one. Scrum and especially Agile encompass many elegant solutions to a wide variety of problems. If you are working on a team that has not encountered these problems the the team may never see the value in the solutions.

 

Having said all that, I'm not giving up on Agile or Scrum. I am convinced it is a better approach for software development. But reality is saying that its adoption is not straightforward and highly subject to disruption. Unless, that is, everyone really, really wants it.


Monday, October 18, 2010 #

For those interested in reading about Agile, here are some excellent titles mentioned during the five days of The Art of Agile Training taught by James Shore and Diana Larsen.  Please leave a comment if I missed any!

 Technorati tags: Agile Agile Books


Friday, October 15, 2010 #

What an ending.  I've just finished the most interactive training class I've ever taken.  I spent much of the last two days on a real Agile team producing a real product in 90-minute iterations.  In a word, it was intense.  It's ingenious to dangle the responsibility for shipping working code in front of programmers during a training class.  It really made the content exceedingly relevant.

After four iterations we shipped a working Java console game that was demonstrated to the class. And I ended up on a development team that, in some ways, is more functional than my development team at work. Seriously, I could take this team back and start solving some real problems very, very soon. At the end some time was reserved for us to express our appreciation for one another. It was a real bonding experience for me. Nerds bonding. What a beautiful, awkward thing.

I've had so many epiphanies and realizations this week.  One is that  we had been doing Pair Programming wrong at work.  First we tried it with too few people, and yes, we got sick of each other.  Then we never traded off more often than once per day, instead of the 2-4 hours I heard today.  We also felt guilty about pairing up piece-meal, since the books said to do it full-time.  When I get back to work I'll be starting this up again part-time on the projects where it makes sense.  We've been doing many other concepts like TDD for some time - but we can definitely do better.

One of the most relevant day-to-day things that I'll be changing about my own coding is adopting Simple Design principles.  Just last week I was using C#'s ?? coalese operator and PowerShell's % shortcut, even though no one else on the team knows what they do.  I confused being current on language specs with being proficient.  And I realized that I often - no, constantly - violate the YAGNI (You Ain't Gonna Need It) principle, building in huge overhead even before I've released.

Being Agile is really about reflecting reality.  My team doesn't have a dedicated Product Owner due to our focus on legacy systems.  Knowing this allows me to push for a PO by justifying it with the efficiencies I've just seen happen.  The class also gave me exposure to companies and developers really motivated to be Agile - you can do this!

Thank you to my classmates Anthony, Hieu, Mike, Michael, and Jesse for being so motivated and cool.

"Agile does not require that people be perfect, but deals with the fact that they aren't." -James Shore

Technorati tags: Agile Scrum


Wednesday, October 13, 2010 #

Day three of The Art of Agile Training (taught by James Shore and Diana Larsen) has been put to rest.  Today we moved into the delivery phase of the training.  In other words, less planning, more doing.  I didn't think we could "do" much more interaction than the first two days, but James and Diana proved me wrong.

My key learning today was the absolutely central role of Test-Driven Development (TDD) in Agile delivery.  To explain how TDD makes me feel requires a story.  About a year ago, while mired in a hopeless project, I decided to change my keyboard layout from QWERTY to Dvorak.  I'd always heard El Dorado-like geek rumors of how Dvorak was incredibly faster, helped to create better content, and made one cooler to women and children.  None of this is true.  But I can give you three metrics.  First, my words-per-minute (WPM) has dropped from 80 to 60.  Two, I make fewer mistakes.  And three, my wrists and hands no longer hurt. 

During the transition, though, I was constantly experiencing an "unsettled" feeling.  It wasn't just muscle-memory of how I used to type.  There was a nagging feeling that something was wrong.  It was like trying to drive while ignoring the engine light - the one that's blinking and means "Pull over immediately."  TDD makes me feel exactly the same way.  If I have fewer than a hundred unit tests, a litte voice in my heads starts saying, "See this test you're writing?  You could be adding business value right now, but instead you're writing this test."  I know it's the right thing to do.  I know it adds quality early and prevents bugs.  But it's still unsettling.

Which brings me back to that  Dvorak transition.  One year later I'm slower, more accurate, and healthier.  I can type longer with fewer corrections.  The primary measurement for success in typing is speed, but I've established a pace that will enable me to enjoy greater longevity and personal satisfaction.  Which all sounds like the benefits of TDD to me.  So maybe that engine light can turn off now.

Instead of a book round-up I'll end with a shout-out to my Ruby-based coding partner for the day.  It was really cool for a C# guy and a Ruby guy to figure out how to code functional Java.  That was definitely a case of paired-programming paying off.

Technorati tags: Agile Scrum


Tuesday, October 12, 2010 #

Day two of The Art of Agile Training (taught by James Shore and Diana Larsen) has finished.  This was a really enjoyable day for me, as it brought together a variety of concepts that had been disjointed in my brain for a long time.

My primary disconnect had been: What ties customer value (say, in a Market Requirements Document) to Agile stories?  How can stories be measured to show whether customer requirements are being met?  And lastly, how can the stories that teams are completing indicate how close we are to actually releasing?

James discussed the concept of a Minimum Marketable Feature (MMF).  An MMF is the smallest amount of work that can be completed and released yet still provide customer value (see "Phased Releases" by James Shore).  A release is comprised of MMFs.  MMFs can be broken into stories.  Stories are then assigned to iterations.  Suddenly by measuring a consistent rate of completion of stories per iteration I can predict when my MMF will be completed with varying degrees of accuracy. 

To take the example further, we know we'll release quarterly.  Based on past experience, we're 90% confident we can ship MMFs A, B, and C.  As we near the release date we become more and more confident in what we can ship based on the measured team velocity.  And just before we ship we can have a crystal clear understanding of what exactly is going out the door.  

Your sales and customer expectations have been continuously set after each iteration as the picture gets clearer.  We have a lot of expertise doing this for waterfall, but Waterfall measures success by how well Scope and Schedule match the initial targets.  In Agile, predictability is the key indicator of success.  With a predictable velocity you can attach a confidence level to your estimates at any time during the project.  I find that extremely reassuring. 

I'll also give a shout-out to the wonderful customer-oriented folks (mostly from Autodesk) that I sat with for the Planning portion of the training.  As a developer it was terrific to be so close to people doing the hard work of product, program, and project managenment.  Every team, including internally focused ones, deserves a good PM.  They're invaluable.

And another book round-up:

Technorati tags: Agile Scrum


Monday, October 11, 2010 #

I'm currently taking The Art of Agile Training by James Shore and Diana Larsen offered by the Oregon Training Network. Rob Myers is helping out, too.  I'm suffering from a bit of information overload and mild exhaustion.

Day one discussed how to use predictable, repeatable iterations as a method for completing work. We had a stand-up meeting comprised of 20 people that lasted only 7 minutes. There were plenty of collaborative exercises, and interestingly these generated a large number of unanticipated questions, many of which were addressed later in the day. I've really taken far too many notes to summarize and recount here at the moment.

The primary class-generated topic was on making geographically-dispersed teams work in an Agile environment. Agile strongly, emphatically recommends co-located teams. So for development teams with resources around the world, we heard advice such as focusing each co-located team on a functional area. And James has an essay entitled "Large Scale Agile" posted on his blog to help coordinate those teams.  There's also a link to a book covering this topic at the end of this post.

While I treasure the information that I'm getting, I'm realizing is that it can be a challenge to put it into practice.  Especially for those working in companies or teams that have been very successful following the Waterfall model of product development.

I'll end with a quietly reflective book round-up:

"Let's make this organization work in a way that works." -James Shore

Technorati tags: Agile Scrum


Saturday, October 9, 2010 #

It can be surprising to see engineers struggle to define work as a project or a task.  A team that can't tell the difference  is displaying a warning sign that it's lost a view of the bigger picture.  Often the team has been focused solely on bug fixes and patches to legacy software.

I think the simplest definition is that a project is a group of tasks that add value to a software product.  This can come in the form of a new feature or improved functionality.  In Scrum, a project is comprised of one or more user stories that in turn are comprised of tasks.  Tasks, on the other hand, are just descriptions of work.  It can be writing a piece of code, testing a program, or writing your status report.  Projects take longer than tasks to complete and (hopefully) provide more organizational value.

From a customer perspective, there's a good chance that customers as a group don't care about the individual tasks you're working on.  They want to know the value and timelines of your projects.  One way to communicate timelines is through a roadmap that describes what work is in progress and what work is planned, usually for the quarter.  Personally I'm confused at why some tasks, like installing software on a server, try to make their way onto our roadmap.  The goal here is to inform your customers about how your projects are cumulatively making their lives better.  Big picture stuff.

If you've been fixing bugs for so long you've forgotten what a project is, I'm sorry.  It does take some experience to know what you should put in your Outlook Tasks and what you should put in your Product Backlog.  What every team deserves is someone in the role of helping to guide the team's work - someone with the authority to create and prioritize projects, someone who interacts with customers.  Someone like a Product Owner.

Technorati tags: Scrum Product Owner 


Monday, September 20, 2010 #

Returning from paternity leave I found my co-workers had redecorated my cubicle in a relaxing, bamboo forest theme (complete with pandas).  It's hard to see the loads of chocolate, the trickling water fountain, or the inspirational sayings on the walls.  Very nice.

Having so much time off helped me to contemplate the year-long debates I've been having about Agile.  Mostly I struggle with the militant "Do Agile everywhere full-time" perspective I learned from the very first Agile books with the feeling that even a few Agile methods could help in most cases.

The most important thing I realized was:  Focus on your projects.  Gil Broza often suggests test-driving Agile/Scrum with a well defined project.  Even experienced Waterfall teams aren't seasoned enough to skip this step and jump headlong into Agile on multiple projects simultaneously.

The other thing I realized that the most pursuasive argument for Agile is to show it produce results.  Apply some Agile practices to long-running projects and you may find that, even if the velocity hasn't risen, more people will be aware of what's going on.

Let others run their projects using waterfall or any other methodolgy (including none).  Use a phased approach on your team where you make sure all of your personal projects use Agile, but don't worry about the rest.  Then do an unemotional comparison - time to market, customer satisfaction, quality of product.  I think you'll find that Test-Driven Design and Scrum project management will be the winners in at least two of those three areas.

Lastly, it's fine to doubt Agile.  I intended this blog to be a place where I trumpet how Agile solved all of my problems, only to be hit in the face with a year of not being able to implement it.  Agile helps software developers better react to their customers' changing requirements and predict accurate deliverables.  If you don't have issues with your customers (or you don't have customers), Agile is irrelevant.  You probably have bigger problems to worry about.

The difference is that I'm now surrounded by ferns and the sounds of a bubbling brook to keep me Zen.

Technorati tags: Scrum


Thursday, April 29, 2010 #

Often reorganized teams end up with multiple copies of work management tools.  Like having three places to gather requirements, three places for customers to submit support requests, three places to plan and track work.

Tools that combine these features into a single product fall into the ALM category.  These may or may not be Agile planning tools, but are tools that allow you to look in a single place for requirements, work items, and reports.

One of the interesting choices is Software Planner by Automated QA (the makers of Test Complete).  It's a lovely tool with real end-to-end process support.  It is a paid tool with a license in the thousands of dollars for a handful of concurrent users.  Still, it’s intuitive, has great Agile capabilities, and has a reputation for excellent customer support.


Another choice is Rational Team Concert by IBM.  Reading the specs on this product makes me want to submit my resume to Big Blue.  Not only does RTC integrate every part of the Software Development Lifecycle, but it’s free for up to 10 developers.  It has beautiful support for all phases of Scrum.

I would strongly recommend the use of a third-party ALM tool rather than writing your own.  Unless, of course, you're going to sell it.

Technorati tags: Scrum Scrum Tools


A simple mistake to make is to assume that the use of Agile methods and Scrum will make everything easier.  Take your teams, make all work visible, track it, and presto: An efficient, functioning software development organization.

Scrum does have benefits like keeping close to your customers and increased predictability.  And it’s true that as teams become proficient with Scrum they tend to become more efficient.  But I don’t think it’s true that Scrum automatically helps people work together.

Instead, Scrum can point out when teams aren’t good at working together.   And it really illustrates when teams, especially teams in sustaining mode, are reacting to their customers instead of innovating with them.

What I’d recommend for any blended team is to look at your current product lifecycles and work on a single lifecycle for all work.  If you can’t objectively come up with one process, that’s a good indication that the new team might not be a good fit for being a single unit (which happens all the time in bigger companies).  Go ahead & self-organize into sub-teams.  Then repeat the process.

If you can come up with a single process, tackle each piece and standardize all of them.  Do this as soon as possible, as it can be uncomfortable.  Standardize your requirements gathering and tracking, your exploration and technical analysis, your project planning, development standards, validation and sustaining processes.  Standardize all of it.  Make this your top priority, get it out of the way, and get back to work.

Lastly, managers of blended teams should realize what I’m suggesting is a disruptive process.  But you’ve just reorganized the team is already disrupted.   Don’t pull the bandage off slowly and force the team through a prolonged transition phase, lowering their productivity over the long term.  Drive a true consolidation.  Destroy roadblocks, reassure those on your team who are afraid of change, and push forward to create something efficient and beautiful.  Then use Scrum to reengage your customers in a way that they’ll love.

Technorati tags: Scrum Scrum Process 


Tuesday, March 16, 2010 #

If there's nothing else to know about Scrum (and Agile in general), it's this:

You can't force a team to adopt Agile methods.  In all cases, the team must want to change.

Well, sure, you could force a team.  But it's going to be a horrible, painful process with a huge learning curve made even steeper by the lack of training and motivation on behalf of the team. 

Even if just one person on the team is fiercely against Agile, it won't work.  It's incredible to me how a single person can strongly influence the direction of an entire team.  Let alone if Scrum comes down as some managerial decree onto a functioning team who have no idea what it is.  Pity the fool.

If you preside over a team process change, it's beneficial to start the discussion on how the team will work as early as possible.  You should have a vision for this and guide the discussion, even if decisions are weeks away.

And anyone in a leadership position should be wary of always rooting for the underdog.  It may feel like this is where a leader can really make a difference, but team harmony should also be taken into account as well.

Technorati tags: Scrum Scrum Process Scrum and Waterfall


Tuesday, December 22, 2009 #

It's nice when well-designed software works.  It's even nicer when you find yourself actually using a tool instead of spending most of your time just figuring it out.  Enter my new favorite project planning tool: Bright Green Projects.

The first thing to know about this tool is that you can sign up and evaluate it for free.  And you'll want to.  The first thing that struck me about Bright Green is that it isn't Scrum-specific.  It can handle traditional Waterfall projects just as easily as sprint-driven Agile projects.  It's terminology-neutral, appealing to anyone who has worked with requirements and releases, while lessening the learning curve to those new to Scrum.

The second thing that struck me was Bright Green's ease of use.  The Scrum tool I'm currently using took several department-wide training sessions to reach about 40% acceptance.  In contrast, every section of Bright Green has a link to a quick-but-relevant training video embedded in the page.  The navigation pane is actually ordered top-to-bottom based on the steps you're most likely to take.  And for a web application, the UI is refreshingly neat and clean, supporting an intuitive drag-and-drop interface.  Well done.

After watching the first few training videos I was creating stories with subtasks, planning my releases and sprints, dragging tasks into their relevant sprint, and moving them around on the virtual kanban board.  And what else is there to Scrum, really?  It's a matter of planning, assignment, execution, and monitoring.  I find myself ready to get to work with Bright Green because I don't need to figure out any deeper, hidden mysteries.

Bright Green isn't free, it's a hosted service with a monthly subscription fee.   It is also web tool that lives in the cloud, so I'm not sure if you can keep your data local.  On the technical side, I didn't see any charts besides burndown charts, and I may want to see release- or product-level progress, user reports on task assignment and task completion, or others.

Overall, though, Bright Green manages to simplify project management into its bare essence, which allows you to actually get work done.  At last.

Technorati tags: Scrum Scrum Tools

 


Thursday, December 17, 2009 #

Scrum Tool is the plainly-titled tool written by the creatively named Zsolt Debre.  Even the product homepage is straightforward: http://scrum-tool.com/.  As you might expect from a tool whose homepage looks like it was written in 1994, Scrum Tool is currently in Alpha.

Despite its novelty, Scrum Tool definitely seems to be heading in the right direction.  It has many hard-to-find features that immediately put it ahead of the pack:

  1. It's a GUI app, not a web app.  You are not constrained by HTML, and application responsiveness is excellent.
    1. Currently Scrum Tool runs on Windows and Linux (Ubuntu 9.04 and Fedora 11).
  2. It's built on top of a PostgreSQL database.  This means you own your data instead of entrusting it to the cloud.
  3. It has a solid workflow.  It understands the relationships between Products, Backlogs, Sprints, Stories, and Tasks.

I'll post some screenshots below.  I've only used Scrum Tool part time, but I like the idea of a robust GUI application that is simple enough to work as advertised.  If you do check out Scrum Tool I'd note that I had some installation issues with the PostgreSQL database on Windows 7, giving me a "Database Cluster Initialisation Failed" error.  Fortunately the fix is simple.

The main GUI:

The first thing to do is to create your Product from the Basic Data->Products menu item:

You can create sprints from the Sprint tab.  I really like that the sprint goal and wiki URL are included in the form:

You can add stories from the Product Backlog tab:

Click Add to create a story:

You can add tasks as children of a story:

And of course charts are built-in:

The internal GUI tool I use today utilizes a tree view to represent the Product->Sprint hierachy, enabling drag-and-drop of stories and default sets of tasks.  There's some double-clicking to be done in Scrum Tool to drill down from your product all the way down to your task.  But I'm really looking forward to seeing what the Scrum Tool team comes up with in future releases.

Personally, although it's officially in Alpha, Scrum Tool seems solid and usable.  I'm going to use version 0.06 for my personal development and would recommed checking it out.

Next tool review: Bright Green Projects

Technorati tags: Scrum Scrum Tools


Friday, October 2, 2009 #

There's a recent blog post that was sent to me in response to my insistence on Test-Driven Development:

"The Duct Tape Programmer" by Joel Spolsky.

The gist of the post is: Good programmers ship software.  I agree.  And my response is: Great programmers ship quality software.

When I wrote commercial software, there were no unit tests.  All testing in-house was done by some internal QA testers, and if the software passed smoke tests it was sent through a full test run.  This could take a week or more.  The schedule was King.

When I wrote code part-time and did full-time Active Directory management, there were no unit tests.  I didn't have time.  I had a full time job, a rotation on the help desk, new tools to write and old tools to fix.  My workload was my boss.

So if you're in the situation where just finishing is a victory, more power to you.  But don't settle there and take a fanboy post to mean you never need to bother with TDD or testing in general.  It could be that you constantly check in timely, buggy code that everyone else hates while simultaneously patting yourself on the back for your Duct Tapey-ness.

Today I'm developing tools full-time to be used inside of the company.  There are two huge differences between intranet software development and commercial programming: Deadlines are more flexible and there is no QA department.  You wrote it, you support it.  For life.

Adopting Test-Driven Development and Scrum has been a survival mechanism for us.  It's the reason my three person team (including myself) can support sixteen production apps.  We don't dare ship bugs, our entire roadmap crashes when we have to rework.

So all I'm trying to say is that you can have your cake and eat it too.  You can have good quality software that you ship quickly - just keep it as simple as possible, build quality into the process, and finish the thing.