Tag Archives: agile project management

The “A” Word

Posted on by
1

Over commercialized, overused and mis-applied the word “agile” has become synonymous with being better, faster, and cheaper.  The hype around the “A” word is nonsense.  Most of the software vendors, consultants, and marketers plastering agile on everything are simply capitalizing on the popularity of some ideas that aren’t even correlated with what their selling.

Agility is not a panacea. It’s not a software tool.  It’s not a product you can buy.  To my opinion it was a state of mind, a way of approaching problem solving.

It’s now lost that meaning.  It’s original luster is awash in a sea of hyperbole and advertising.  When someone says they’re agile or they practice agility….I no longer know what they mean.  It might be that they read a book, they use some self-professed agile software tools, they have a poker planning card set, they bought a CSM certification, or they recently attended some conference on agile software development.   Stop Agilizing Everything was written in protest to the fluff, and monetization of agility.

Will it stop?  I doubt it.

Instead it will kill itself through abuse. Eventually it will become the worn fad of the day.  In disdain and disgust we’ll turn our backs on the “A” word and seek something with more substance.

Advertisement

The Coming Breakup of Scrum

Posted on by
2

Introduction

Scrum, probably the most widely adopted agile software development practice, is cracking up.  The signs are evident and this article discusses the trend and what it means for agilists today.  If you practice scrum, are thinking of using it, or have used it in the past you’ll find interest in this article.

Oh yeah?  Prove it!!!

It’s a truism that rapid growth and popularity put a strain on organizations, movements, ideas…….or ,more fundamentally, the people comprising these very human vehicles.  As an idea ferments and then exponentially amplifies to encompass a wider politic of devotees and admirers there is the impending fog of dissent with the origin, the core.  From this comes splintering, debate and eventually more novelty and innovation.

Fine, but what about direct evidence for the rift in scrum?

03/05/2009 – Scrum But…Test.  Jeff Sutherland.

09/15/2009 – Ken Schwaber resigns from Scrum Alliance

06/15/2010 – Ken Schwaber establishes Scrum.org

04/20/2011 – The CSM certification wars

07/26/2011 – Forrester calls Water-Scrum-Fall the norm

08/02/2011 – Bloggers Suggesting Scrum Variations

10/06/2011 – Scrum Extensions announced – allowing modification to basic scrum.

As the agile movement hybridizes and evolves scrum is feeling the brunt of this pain. The forces of hybridization are ripping scrum into distinct camps whose views are aligned with their respective organizational needs.  Who are these camps and what will ultimately happen to scrum as this spider web is tugged from it’s anchors?

The Camps

The Enterprise – Most enterprises don’t build software as a core part of their operations.  Projects here are usually centered on delivering some base set of functionality for a fairly fixed price.  Stability and low cost of operation are prized.  The organization doesn’t usually see this as an investment…but as an expense to be managed and tracked.  The pressures enterprise software development groups face at the capital planning phase and the release phase have sculpted the Water-Scrum-Fall that’s prevalent.

The Software Companies –  In contrast to the enterprise, software companies build software as their core product.  It *IS* their operation.  Software companies see their products as an investment and it’s life cycle is fairly unlimited, or at least tied to the life-cycle of the company.  Pure scrum works in  these companies fairly well.  There’s usually still pressure to reduce the number of production releases but on the planning side managing features in a backlog fashion is workable, even preferable when you have a product that has a potentially unlimited lifespan.

The Startups – Startups face a different set of pressures from their venture capital investors.  The need to rapidly introduce new features and create value to customers and investors by gaining a competitive advantage quickly is paramount.  Startups are tearing scrum towards the Lean Startup methodology professed by Eric Ries.   The focus here is continuous delivery of new software: stability be damned.  Usually these startups don’t build software that’s mission critical or life threatening.

The Purist Methodologists – Among these are the various scrum trainers, agile coaches and general agile philosophers who profess a puritanical approach to scrum.  Their insistence on a dogmatic approach to scrum are rooted less in practice and more in theory.

What are they doing to scrum…where are they taking it?

These groups are doing what’s natural.  They’re catering scrum to their practice and profession of application life-cycle management ( ALM ).  But this tug of war for scrum’s future is changing it.  Instead of a simple, one-size fits all methodology, it’s becoming a framework of patterns & practices.

You can see this through the introduction of scrum extensions, which is a natural way of recognizing the various groups that have adopted scrum in some fashion.  With scrum becoming an umbrella concept, it’s importance is melting away.  It will devolve and eventually disappear. Instead the extensions, much like design patterns in software development, become the value added pieces that development teams will use and rally around.  Each camp will likely pool certain extensions, patterns as their ‘methodology’.   In time, these flavors of scrum will tear it completely apart.

Summary

Scrum’s popularity will likely be its undoing.  But is this something to be avoided or stopped?  Hardly.  Hybridization and evolution of scrum is a natural process that is both pragmatic and necessary.  Jeff and Ken’s baby is growing up and leaving the agile house.  The original agile manifesto signatories accomplished their mission; they broke the one size fits all ALM world down.  The new heterogeneous landscape of practices and patterns, while less clean than the bi-polar world of agile vs waterfall, is primed with greater opportunity for innovation.

Santa’s Workshop Goes Agile!

Posted on by
2

Among the aroma of fruit cake, hot cider, and sub-zero temperatures Santa Claus announced today that his North Pole Workshop would switch to using agile practices in toy production.  Santa sighted a number of reasons for the change, among them:

  • Increasing need to be first to market against growing competition.
  • Better collaboration between kids’ toy lists and toy developers.
  • Reducing the risk that kids don’t get what they want.
  • Increasing quality and accountability in toy development and delivery.

According to Santa, “We’ve analyzed this decision for some time and  it became clear that change was needed after re-reading little Timmy Todsnockerdellturtlefoof’s complaint letter from last year.  Instead of receiving a bicycle, as stipulated in his toy list; he got two fake icicles.”

The well publicized failure last year to meet the requirements of Timmy’s wish list was not the first time Santa’s North Pole Workshop hadn’t delivered, but in this day of social media and instant updates; the story took on a vicious viral characteristic….hitting #1 in the tweetosphere for a full month with the hash tag: #TimmyTodsnockerdellturtlefoofGotIcedBySanta.

When asked what type of agile practice the workshop would be adopting, Santa replied: “Scrum.  It’s well known, proven, and being used in some isolated corners of our workshop today.”  Some muted ‘boos’ could be heard from the audience.

Santa went on to say that Rudolph The Red Nosed Raindeer would head up the agile transformation of the North Pole Workshop in conjunction with an outside agile consulting firm to be named later.  That development confirmed for some that Rudolph was next in line to take over The North Pole.  Rudolph was on hand to comment to reporters after the announcement:

“We’re looking at one of the big 5 consulting firms, but we haven’t ruled out the smaller players.  Look, what’s important here is that we get to done. I have a nose for this kind of thing.  I’m not a dreamer..I’ve been a servant leader for a long time…I realize this transformation isn’t going to happen overnight, there will be pain and there’s a lot of existing process and procedure that will have to….well, frankly….go away.  But, one step at a time. I expect we’ll have a more detailed plan in May or April.  Talk to me then.”

Reactions among the North Pole elves was varied.  One older elf man pointed out that Santa had to be dragged “kicking and screaming to the decision.  He wasn’t on board at all.  Rudolph, Frosty, Mrs Claus and the Yeti really had to sell him on it.  When they broke out Timmy’s letter to remind Santa of the increasing defect rates in his shop….he went ballistic. I mean he really lost his cookies.  Then the Yeti put his foot down.  I think Santa knew what that meant.”

Others, like a younger elf woman, had a different opinion on the switch to agile:  “I’m fine with the whole agile thing, but I guess I don’t understand why they chose Scrum?  I mean….from what I read XP is way better and more applicable to our environment.  I really don’t think the elves, particularly the older ones, will like daily stand-ups. I mean most of them can barely wake up every day….let alone stand up.”

Still another view was held by Donner, “What about Kanban?  No one’s talking about Kanban, but in the reindeer house we use it all the time to limit HIP ( hooves in process). I bet Rudolph moves us there.  I think there’s going to be a power play here between Santa and Rudolph.  It’s a battle that’s been brewing for centuries.”

“Give me a break. Agile?  Really, let’s knock off the buzz and hype.   So we goof up on a few thousand toys out of the billions we make a year.  How’s agile gonna solve that?  I don’t get it.  I guess I’ll ride it out and see where this goes.  But limiting HIP in the reindeer house has done nothing but give some of us more time on our hands.  I don’t think that’s what Santa wants.”  said Blitzen.

Frosty, while at the announcement, declined to make any official comment but did say that he favored a balanced, pragmatic approach, one that would focus on the workshop’s needs rather than a dogmatic approach.

Mrs. Claus had this to say: “Rudolph is very bright.  I know he’ll make this work.  He knows where he’s going.”

Strangely, the Yeti, was not present.  But his footprint could be found in the comments that others made.

Outsiders also came to hear the announcement.  The Easter Bunny had this to say: “I understand what Santa’s doing and to be perfectly frank he’s in a different position from us in Easter Hollow.  He’s facing some real time to market issues and competition with Mom & Dad, Grandpa & Grandma, and others.  His competitors have real advantages in local sourcing, customer relationship management, and technology.  Santa just hasn’t kept up and now it’s time for a radical change.   I don’t think anything he’s doing is going to change our approach.  We pride ourselves on stability of delivery and with a 98.2% market share on Easter…we’re just not facing the same issues.”

The Easter Goose has the other 1.8% of the Easter market.

Merry Christmas agile community.  Enjoy your holidays, stay safe, and as always….take care. 😉

Who Should Be the Scrum Master?

Posted on by
6

Who is this article for?

All software development professionals will find interest in this article, but those hoping to adopt agile, and scrum in particular, will find the greatest interest.

Project Manager or Technical Lead

Who should the scrum master be?  There’s at least two schools of thought that find gravity with this question.   One position is to employ the project manager in this role.  Another position is to have your technical leader tackle the position of scrum master.

Justifications for both can be made.  The project manager naturally has the people and process management skills required to successfully unblock nettlesome issues vexing the development team’s path to productivity.   But on a deeply technical project, unless the PM is fairly technical, he/she could end up at a disadvantage to a more traditional technical lead.  Hence, the argument to have your key development lead be the scrum master is born on the wings of a sufficiently technical project. Of course, this later position has the down side of potentially drawing the Peter Principle forward in all its majesty.  You hired Sam for his technical ability and now your taking him out of his strong suite.   Rarely a good move.

What about a CSM?

With the emergence of the Certified Scrum Master ( CSM ) credential software development directors are asked whether it makes more sense to get a professional scrum master to do the job.  This seems logical, and in some cases may present the right option.  But for those with experience and discernment, a certified anything is only a guarantee that the individual has at least passed some training and testing.

CSM’s may come to the role with the theory locked down, but it would be advisable to ensure they’ve ‘done it’ and can ‘prove it’.  A heterogeneous grouping of experiences and project types would be a good background for any CSM.  Awareness of any subject matter is important, but knowledge gained a priori has its limitations in the field of software development, indeed most worldly pursuits.  Experience counts deeply, and those who’ve been salted through the mine fields of time and circumstance can and do turn tricks the books don’t tell.

Rotate the Scrum Master Role Among Developers?

This seems like an interesting idea.  Seems is the optimal word here.  Rotate the role among developers and give them a chance to self organize.  After all, this is one of the scrum principles.

Boldly, we did this in my shop.  I can tell you first hand…it doesn’t work very well.  The results were not disastrous, but mixed and inconsistent.  The scrum master is there to facilitate and unblock key issues and risks.  By nature, most developers are not wired for these skills.  In most cases their preference is to solve deep, but abstract problems and/or utilize their creativity to bring their imagination into the world.  The scrum master’s world is never abstract and the problems rarely have a logical conclusion.

Here’s some examples of what occurred during our rotation experiment:

Developer 1 would take all blockers to the development manager and ask him to unblock them.  Dump and run.

Developer 2 saw the scrum master role as a break from developing software.   He was increasingly sick of writing code.  He’d often take over the other developer’s turns as scrum master and before long became the defacto scrum master….just because everyone else didn’t want to do it.  But he wasn’t good at it.

Developer 3 just wouldn’t do it.  When asked why…he gave the perfectly logical answer: “I wasn’t hired to do that job.  I won’t be good at it.”

Developer 4 was great at staying on top of all the details, and orchestrating/facilitating the scrum process, but his natural timidity meant he found it difficult to press upon others for project needs.

Qualities Not Titles and Credentials

So what are we left with?  If job titles, credentialing, and current software development roles offer no guarantee of a successful scrum master than what does?

Here, I would contend, from experience, that the qualities below are essential for a successful scrum master.  These may differ from more traditional scrum teachings, but I offer them up as opinion and reflection to the agile community.

A Driver – First and foremost the scrum master should be a bulldozer.  The person filling this seat should feel comfortable pushing issues forward and untangling gray, often ambiguous problems unaided by higher-ups.  I do believe this differs from the views of Scott Ambler, Ken Schwaber and other scrum proponents.  When they speak of a ‘coach’ one gets the sense the ideal candidate would be equally comfortable leading a Little League Baseball team.  But organizations with size and high market caps are serious and very adult places requiring thick skin and persistence forged in steel.

Detailed and Organized –  This really goes without saying.  A scrum master that is uncomfortable with the details of the software architecture he/she is helping to birth into the world is headed for trouble.  One doesn’t need to be reading the code, but it would be beneficial to have the skills to speak with developers on their level and translate those into business speak.   Being organized is also a natural quality for a scrum master.  As orchestrator of the scrum process he won’t gain any points from the team if he forgets that today is iteration planning or can’t recall which stories are resolved.

Honest With Himself/Herself – No one likes a liar.  It’s easy to be honest in the face of fair winds and successful deliveries.  But, when the rice pudding hits the fan and the scrum master and team are to blame:  a solid scrum master will set the example, take responsibility for the mess, apologize, and find a corrective course of action.  In a nutshell: lead.

Politically Astute – The nuances of human behavior and relationships inside organizations that scale to 3M and GE proportions are not to be trifled with.  A bulldozer needs to know when and where to stop plowing and let a more suitable piece of machinery take over.  Further,  the scrum master should have a bag of tricks.  He should be comfortable in the art of persuasion, know the hooks and hot buttons that pull and push his key stakeholders, and see the organizational hierarchy as a tool rather than an impediment.

It’s Personal and I’m Fully Invested – In my experience, aloof scrum masters don’t do well.  They should see their role, project, and career as intertwined.  Their reputation should be at stake and success to them should be more than just a good stand up meeting, or a well orchestrated iteration review.  None of that matters should the product miss its goals. They should take this personal, and invest themselves fully in the project.  Again, this is leadership. Projects rarely fail because money, time or ideas are lacking.  Their usual course to being shipwrecked starts with….belief.  People need to believe the project will be successful and the scrum master should be its evangelist.

Humility – Lastly, I agree with most other scrum theorists that the scrum master should be humble.  I think this is called ‘servant leadership’ by them, but I’d chalk it up as just good leadership skills.  A good SM won’t boast or take credit for other’s work, but place credit where it is most surely due.  Let me be clear, I’m saying ‘humble’ not ‘without backbone’.

Summary

The picture that emerges for a good scrum master candidate is a leader; not a secretary or a bureaucrat.  My view on this differs from traditional scrum thinking.  Where they see a helper of the development team, I see the scrum master as an active, engaging and dynamic person with a big stake in the game. He or she could have certain titles or credentials to his or her credit or not.  Like so many other leadership roles the core of  what that person accomplishes will be manifested through who they are….rather than what hard skills they may possess.  When interviewing and reviewing potential candidates I would keep this question in your mind: Will the development team and stakeholders believe in this person?  Your project may rest on the answer.

Can Agile Work in Big Organizations?

Posted on by
1

Who is this article for?

All software development professionals will find interest in this article, but managers, CIOs and software architects will find the greatest interest.

Can Big Organizations Rapidly Change?

Think about the last big company you worked for.  Did it move fast?  Change overnight?  Did anything get done ‘quickly’?  Weren’t there gobs of jokes about the ‘bureacracy’.  Big companies run slow.  When they need to move fast they put people outside the organization or buy smaller companies.  Change is just not a priority inside a company like this unless it is facing financial issues and agile presents a significant challenge to the orthodoxy and bureacracy of such a beast. But is that a reason to not attempt agile in a large corporation?  No.  But it is a reason to have a different strategy for a change adoption.


Hybridization of Agile:  Pragmagile

Yes….but you have to be pragmatic.  What I mean is that you’ll need to realize that this bureacracy and the people in it were bequeathed their titles for a reason.  They’re successful, to a certain extent, because they know how to get things done despite all the red tape and foot dragging.  As an agilist, these people are not your enemies despite their gantt charts and stakeholder evaluation matrices.  They’re your allies, your tools to be upwardly managed.

So considering this I’ve compiled a list of tactics that I think may be helpful for any agilist hoping to succeed in a large professionally heterogeneous company.   Here they are….let me know if you agree?

1. Follow the principles of The Pragmatic Manifesto.   Key among these… is embracing everyone…not just the software development team.  See everyone as having value and being able to participate and contribute to your software development process.  Be pragmagile.

2.  Walk it, don’t talk it.  Show your company agile works.   Don’t go around preaching it and extoling its virtues when you haven’t even delivered one project yet.  You might even want to avoid the word ‘agile’ altogether and just say this is how I like to work:  meet every two weeks, go over any changes, hedge the risk that we don’t understand, and adjust project course as needed.

3.  Help your project sponsor help you.   Your project sponsor in a large corporation is likely a veteran of the company.  Don’t discount this as ‘stuck in the old  ways’.  They know stuff you don’t and they can help you stay in good graces with all the red tape barrons.   Keep a solid, open and agreeable relationship with your project sponsor.

4.  Give a little, get a little.  Another way of saying this…….don’t be dogmatic.  If someone doesn’t like some aspect of your agile approach don’t automatically write them off.  They may have good reasons for their objection, and by showing your concern and willingness to adjust…..you’re demonstrating a core tenant of agility.    If stand-ups are hard for people with back issues, then try a 15 minute conf call.   If the customer just can’t meet every two weeks, then try every month or on a more lucid schedule.  But above all…….be flexible.

5.  Focus on the goal.  Delivery of your project/product is what you’re after.  Not agile adoption by your company.  Maybe you’ll get this as a side effect, but honestly…….you probably weren’t hired to evangelize the enterprise. Furthermore…you can’t do it on your own.  Put your accounting hat on and think hard-ball.  Git-her-done.

6.  Seek to understand the culture and the history behind it.   Maybe your company doesn’t move fast on this software project because your building something that its enormously complex and could kill someone if not done right.  There may be very good reasons for stifling rules and countless reviews/approvals.  Work with the grain of the wood…not against it.

7.  Stop assuming everyone wants to be agile.   Worse yet, stop assuming everyone knows what it is.  They may have heard about it and chalked it up to no  more than a new process.  But those of us who’ve lived it know that the real change is cultural.  It’s a tough shift and it won’t happen overnight.  Be patient with those around you.  They’re trying to learn and you’re there to help them along.  Be prepared for the guy who says “Agile sucks and here’s why…”.  He may have valid reasons for his opinion and discounting him will only deepen his view.

8.  Figure out the commitment level up front.  I wrote about this in another article:  Are You Committed?   But, essentially the team is supposed to commit to the iteration at hand.  But….what does that really mean?  Commitment is one word with many different interpretations.  Don’t assume you know how much the team is willing to commit and don’t assume that the companies HR policies and benefits jive with the agile philosophy.

Summary

That’s it.  I know I probably should have run it up to 10 ( don’t all good lists round up to 10? ), but I’m not going to throw down fluff just to reach a number.   It’s been my experience that if you make agile work in an organization people will just naturally ask you:  what’s your secret?  Why do your projects work out while other projects fail?  If you get to this point then I guess it’s ok to preach a little bit, but step off the soap-box when you feel your head getting bigger.   😉

Decline of Written Requirements

Posted on by
4
Introduction
Requirements managers, project managers, and business analysts will find the most interest in this article. Developers will find a nice challenge at the end.  🙂   In this article, I attempt to show that written requirements are no longer necessary….and a new tool, using new media….is necessary.
Why did written requirements fail us?

Requirements gathering, analysis and management has never been easy.  It’s hard work filled with nuance, half-truths, mis-interpretations, ulterior motives, impressions, imagination, emotion and misunderstanding.  It’s vision crafting.
Getting everyone on the same page to a clear and sufficiently detailed model of the proposed system requires a conductor with the right skills.  Too critical to be ignored, a lack of depth in this area can doom a project.
To help codify that vision the software industry quickly turned to documentation and documentation standards.  But, written requirements have proven to  be an inadequate fit with the abstract nature of software and these flaws became apparent:
  • “That’s not how I read it”
  • Versioning Changes
  • Big complex software = big complex requirements = never read/hardly understood
It was realized by a myriad of software professionals that relying exclusively on the documents and omitting en
gaged conversations to clarify the written word was a mistake. But….spoken requirements and conversations have these flaws:
  • “That’s not what I heard or understood.  That’s not what I remember.
  • Hallway conversations, informal clarifications that aren’t heard by all parties.
  • Complex requirements can’t easily be remembered, conveyed through conversation alone.
  • Change management is non-existent.
User stories attempt to blend the spoken and written worlds and emphasize the continuous interaction between customer and software development team.  They rightfully restored the need for conversations and engaged business domain involvement and got us away from the never ending refinement or versioned requirements books.  They get us closer to where we need to be.  But, they still miss the mark.  Some flaws of user stories and their crafting are becoming apparent:
  • Software and business teams change…..leading to a loss of highly valued historical domain knowledge that may or may not be documented in the code or the story.
  • An awful lot of time is wasted writing these down, editing them, and then clarifying the exact meaning.
  • It’s a fine line.  How much to write?  How much to discuss?  Too little and the story is worthless.  Too much and we’re back to writing all our requirements.
  • Complex business domains and logic need to be documented in detail.  A simple story ( or many simple stories ) with acceptance criteria may not be enough.  Think about requirements for the Boeing 787 flight control system.
  • User stories assume the business owner will be available ( static ) for clarification during much of the project: not a safe bet.
Where are we headed?

With the proliferation of digital video, cell phone cameras, webinars, social media, and whiteboards we have a new set of building  blocks to create the 21st century requirements management tool.  And that is my challenge to the community.  Build it.  Use these pieces to create a new tool for managing requirements that further reduces the risk of interpretation.  Here are some advantages I see:
  • The historical integrity of that requirement conversation ( and its vision ) would be preserved for any future teams to review and understand it….nuance and all.
  • Verbal as well as non-verbal communication would be preserved and could be analyzed later for better realization of the requirement.
  • Whiteboarded artifacts could easily be recorded and saved along with the video.  Adding to a thorough documentation of the conversation.
  • While this wouldn’t completely eliminate the need for clarification of requirements; it could sharply reduce it.
  • Productivity in requirements gathering  and recording could potentially jump helping out the entire software development process.
If you feel you’re up to the challenge…:)….then contact me ( chris@effectivelogic.biz ) and I’ll give you further guidance requirements.

About the Author

Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager  throughout his career.  Chris writes on his experiences and ideas at his blog: http://www.anagilestory.com.

The Bad Attitudes of Agile

Posted on by
1

Who is this article for?

All software development professionals will find interest in this article, but managers, CIOs and software architects will find the greatest interest.  The topic may be controversial to many, but I offer this article as insight into what seems to be a growing problem in the Agile movement.

“Why are you here?  Agile doesn’t need managers.”

Ever hear this one before? Imagine how shocking it is to hear that the developers think your position shouldn’t exist……as if you as the manager had some contribution in creating that position.   It’s most commonly directed at project managers as they first meet the development team they’ll be working with.  To be sure the original Agile Manifesto makes absolutely no mention of project management and subsequent agile theorists go further and suggest adjusting the project manager role to be more of a coach or support role.

However, this view ignores reality.

Small non-integration dependent development projects, to be sure, probably require very little supervision of any kind as long as you have a competent, experienced and capable team.   However, the larger the project, the more integration dependent the project, and the less development centered the project…….the more a project manager is needed to coordinate, communicate and lead the overall effort.  A project in which the development portion is only 10% of the overall budget can allow a scrum master to lead the development while reporting to the project manager.

Furthermore the development team is almost never aware or good at managing a budget.  The amount of time required to develop software requires that little time be spent on anything else.  This creates a bit of a blind spot for some developers as they begin to believe that everything they are doing *IS* the project and that anyone else is just a peripheral annoyance.

The bad attitude here is the inability to recognize other roles and professions as having value and strictly adhering to a philosophical interpretation without recognizing the need for flexibility given the winds of reality.   If taken too far the attitude can come across as almost unionist or neo-communist in its presentation by extending the view to all management in all situations.  Surely the individual who adopts such an all-encompassing wholesale reduction of the corporate culture and organizational structure into one flat level is a radical.   His views are on the periphery, but if he’s the right person ( a leader ) his views can gain traction and worsen the relationship between the development team and management; turning the goal of project completion into a class warfare between management and workers.

“The team runs the project, not the managers…….we’ll decide what gets done.”

This view is often an outgrowth of the notion that management roles are no longer needed.  It flies in the face of the truth; that many decisions require collaboration among many elements of the company; not just the development team……..including the software design and architecture.

In other instances developers positing this notion are just unaware that there are other aspects to a project.  Or even worse a developer has been burned terribly by a bad experience and feels the need to “take control” of the project before some perceived breakdown occurs.

Regardless agile becomes the pre-text,  a foundation, for an attitude which suggests that most, if not all, the management structure above the development team has no contribution and should be summarily removed from contribution to the effort.  Letting this attitude take hold, in my experience, usually results in endless re-architecture sessions, severe budget-overruns,  no real end date, and a fractured emotional team that becomes disillusioned with its own mission.

“There are no due dates or schedules in Agile.”

Those of us with deep insight into capital budgets and corporate finance know how silly this is.  However, if you read Ken Schwaber’s Scrum book it does talk of abandoning the Gantt chart for a burn down chart.  In truth the burn down chart is a neat and well thought out innovation, but there are those who take this to mean that there is no schedule for delivery……i.e. the money never runs out.

This was a painful experience for myself.  I watched as a team led by a strong, charismatic technical leader ,whom we all reported to, abandoned any time based goals in favor of just producing a “working product” for the customer.  Without any time boundaries the team careened every which way.  Work ethics declined or were non-existent.  Those who wanted the product to succeed lost any motivation and drive.  The customers became bewildered as to why so much emphasis was being placed on various technical architectures while features and product change requests became lost.  The burndown charts further confused them.  All they really wanted to know was; when will the product be complete?  The team would only respond with; “We’re not on a schedule. We keep developing until we’re done.”

 When attempts were made to set realistic goals by anyone; they would immediately get knocked down as “anti-agile”.   When the team was informed that their project was hopelessly over budget; their eyes looked clouded, and confused.  The connection between what they were doing, time and, ultimately, money had become lost in the abstract design patterns etched on their whiteboards.

Realistically…….there is always a due date and a schedule for delivery; explicit or implicit.  No one puts up money for a development project with the view that it will never complete.   Even more realistically, I’ve found that Gantt charts are still very useful for coordinating deep integration or non development aspects between non-agile teams and agile teams.

The no schedule attitude arises mostly because agile techniques put forth the notion that the project should continue to add new features until the money runs out.  This is ideal and ignores what happens when a development team hasn’t even completed the bare minimum of functionality within the budget; rendering the application useless.  The bad part of this attitude is taking a new technique for tracking team progress and accountability and twisting it into a reason for not being accountable for delivery.

“Agile code is self documenting.  There’s no need for requirements, architecture diagrams or technical specifications.”

If you are a software architect or technical manager this attitude is usually targeting you between the eyes.  The thinly veiled attack is meant to question your role, experience, and the need to have anyone coordinating the overall technical design of that 28 million line software program that generates 78% of the company’s revenues.

Certainly it is often put forth by ignorance.  Maybe the 2000 line web app that the developer built recently required very few artifacts beyond the source code, but scale matters.   You know that, your management knows that, but this bad agile attitude chalks up your role to not staying current on development techniques like Scrum.  Major software systems require that a few minds are overseeing the direction and coordination of the technical vision and the many hundreds of hands creating it.

In my own experience this attitude came from a developer who, ironically, wanted to be one of the architecture staff.  He felt by critiquing and arguing with the technical leaders and introducing his knowledge of agile techniques they would respect him more and give him the coveted position he craved.  Instead, they found him to be annoying and a troublemaker.  Furthermore his lack of tact in introducing agile concepts left the senior technical leaders with a bad taste in their mouths for anything agile.

“Agile rapidly embraces change; all change.”

My experience with this attitude came from a manager instead of a developer.   It turned out he read “rapidly embrace change” to mean all kinds of changes……not just business requirements as was intended by the original agile creators.  So, fundamental architectural changes became commonplace and shifting between different open source technologies was seen as ‘good’  even though this meant taking the team completely away from their skill sets and setting project delivery back by months.  Organizational experimentation and rapidly dropping people in and out of roles also became part of  ’rapidly embracing change’.   The end result was a mess.

Clearly accepting change presented by customers is important, but without a system for managing that change; you’re asking for trouble.  One needs to keep track of all requirements and changes and their impact to project delivery so that this can be communicated to customers.  This is necessary to make effective project decisions.  If you don’t then the customers get the unrealistic notion that anything they ask for will be included……we know where this leads.

So the bad attitude here is accepting change without managing it.  An unmitigated free for all will only lead to dashed hopes and unmet expectations.  Change is good, but violent change is chaos.

“Agile uses generalists; we test our own software.  There’s no need for a QA group.”

Again this view is accurate in philosophical interpretation but my experience with this on, especially large, software development projects is…….you need a 2nd set of eyes looking at what the developers created and how well it works.  Pride of workmanship is great and should be fostered, but sometimes pride can turn into blind acceptance and defensiveness.  It takes a strong and deeply honest person to recognize their limitations and find ways to mitigate them.

Using generalists puts emphasis on making sure you’re staffed with a nimble group of multi-skilled individuals.  In reflection this recognizes software development as mostly craft and less production assembly.  However, as software development leaders we can’t assume perfection in human resources and ignore the facts.  It’s better to see the risks and plan for them and history has proven that developers don’t find all their own mistakes.

In my own experience the individuals holding this view disliked anyone testing their code and were prickly to any constructive criticism.  In one case in particular we found the underlying reason was because the developer really wasn’t that good at coding.  He was given training and mentoring and after many months of struggle it became clear that he was on the wrong career path. 

So using generalists is fine, but the attitude becomes stale if the hard truths of decades past are ignored in favor of philosophical purity.

Summary

In conclusion these problems could be found in the pre-agile world as well.  But in my experience these bad attitudes are finding refuge and justification in a new technique that in isolation probably never intended to present such a soapbox.  As software development leaders it’s critical that we address these viewpoints before they take hold of the agile methodology and potentially darken a good movement.   Agile has a great message; simplify, engage the customer during the product development, take ownership, and stay connected.  It would be a great disappointment to see this message lost.  So what do you think?  Are these attitudes in your shop?  How do you address them?  I’d like to hear from you.

About the Author

Christopher R. Goldsbury is a software development professional who has played the roles of developer, architect, scrum master, development manager, project manager and quality assurance manager  throughout his career.  Chris writes on his experiences and ideas at his blog: http://www.anagilestory.com.

Agile Finance – Story Point Cost

Posted on by
Reply

Who is this article is for?

This article is written for those with management and budgetary responsibilities for a software development project or team. Others, including developers, quality assurance personnel, and CEOs/CIOs may find interest.

Why would we need to estimate story point cost?

Story points are used to estimate work. Investment in that work is expected to derive some benefit. If that benefit is expected to be financial then understanding the cost of that work is essential to deriving any meaningful ROI. Even if no ROI is expected and the intended benefit is regulatory compliance ( as an example ) then company leadership usually wants to understand what how much of their limited financial resources is going towards any specific feature, iteration, or release.

How do we do it?

The technique presented here is a historical parametric approach. It relies on past data from previous projects. So, one has to have some of this data saved up before a reliable figure can be derived.

RC = Total dollar cost for a historical releases in a product

RSP = Total story points that contributed to that release.

RSPC = Release Story Point Cost

RSPC = RC/RSP

Once you have this for one release you should calculate it for all historical releases. The next calculation is an average:

Average RSPC per product = ∑ RSPC¹, RSPC²……..RSPCⁿ / N

If you want the story point cost across all products then average it again. Although, for most planning purposes it’s useful to plan by product line and this higher level of abstraction of cost might be too watered down.

What questions does this help answer?

  1. How much will it cost to add this feature?
  2. How much will it cost to deliver release 2.1.0 ?
  3. What is the cost of an average iteration?

How often should it be updated?

The astute among you will notice that we’re using historical data. Historical data is only accurate as long as change doesn’t take place. To counteract the shift and change in time size, capability, and mix one needs to do these calculations at regular intervals. How often? This is a judgement call. I do it monthly as I’m in rapidly growing team with many new products popping up. I constantly need to reassess my cost driver.

A more stable team and product might require only 6 month intervals. The relevant point here is; keep it accurate.

Summary

Story point cost ties a rather abstract and developer centered concept to the real world of business. This is necessary. If we intend to use story points in a meaningful fashion in our development environments than they must have some corollary to the spreadsheets, and ledgers that the world’s businesses run on.

Why Does Agile Adoption Fail In Some Organizations?

Posted on by
Reply

Introduction

How often do you hear that a company attempting to adopt agile practices fails?  This article attempts to examine and explain the often overlooked key organizational reasons that agile fails, why it isn’t obvious to most of us and some potential strategies for coping with organizational impediments.  The article’s target audience is managers with budgetary responsibility although technical groups might also find interest.

Historical Perspective on Agile

Where did agile practices originate and why? The Agile Manifesto was originated by a group of software developers.  Their main pupose in creating a new software development methodology was to address some of the core problems with traditional waterfall techniques, specifically: risk around changing requirements, late feedback from quality assurance, and accountability of the development staff.  Their focus was not on how this methodology worked with the budgeting and financial aspects of a funded development effort.  In the information technology world there are two types of funding models.  One is a large  company that sees the software product as its bread and butter or at least a key differentiator for its business model ( think Oracle, or Scotttrade ). We’ll call this company X.  The other model is a company whose development effort it not critical for their overall business model and  the resulting funding is a fixed bid.  This is company Y.

Why is this important?

The answer lies in how the development effort is viewed by company X and Y financially.  In company X the software development effort is viewed as an investment, indeed the primary investment, in the company’s future.  In company Y the development effort is a small application and is viewed as an expense to be time bound and tracked.  In company X the team is funded.  In company Y the project is funded.  Read those last two sentences again.

In company X agile will succeed.  In company Y agile will fail.

In a fixed bid development effort the software development is intended to end at some point. Securing funding for the project requires that you define it up front, estimate it, resource it, develop it, test it, implement it, and then turn it over to support.  This is company Y.

In a time and materials funding scenario the company determines it has need for a software development team as there are many projects that require development well into the future.  An estimate of how big a development team they can afford is created for the budgetary time frame (1 year, 2 years), it is resourced, and then project scoping and scheduling are done.  This is company X.

See the difference?  In company X there will always be software development.  There is no end and the team is funded with that intention.  So putting that work in a backlog, prioritizing it, and estimating and reviewing it in time boxed iterations makes sense.

In company Y the effort can only afford to be funded for some subset of the budgetary period (say 3 months).  After that there is no more money or the company is unwilling to allocate additional money.  They don’t want a long term development team because they can’t afford it and besides there wouldn’t be enough development work to keep them busy anyway.  So deep controls and strong project management is required to ensure that something is delivered in that 3 month period.

Viewed this way…..financially, agile is a luxury.  It assumes that you’ll always have a software team and there will always be development work.  It assumes you’re team is funded year after year and you, as a manager, don’t have to worry about funding individual projects.  As an agile manager you’re primarily concerned with schedule, scope and capacity.  Budgets are an annual or bi-annual thing.  You flex up or down depending on the economic realities facing the company.  The criteria for success are largely centered on functionality delivered over time.

In company Y you might have $50,000.00 that is set aside to complete you’re project in 3 months.  Budgeting and expense tracking are critical and will determine whether the project is a success or not.  A manager here gets funding on a project level at various times throughout the capital cycle.  You may deliver all functionality on time and over budget, but that won’t be seen as a successful project.  As a manager in this company you are concerned with all 3 legs of the iron triangle.  Your team is likely temporary and staffed by contractor labor. Adoption of agile in this situation is a mistake…..even superficially. Why?

Estimation

The key lies in estimation.

In an agile software team you don’t estimate your work till right before you begin.  And you only estimate, in the case of scrum, the next iterations work. So how do you know how long it will take?  You don’t.  Furthermore, you really don’t care.  You’ll continue to deliver functionality every iteration.  As soon as product management and QA say you have a good enough product; it’ll be released as a production version.   You might have a guess, but until the team estimates it….you really don’t know long it will take.

In a fixed bid situation….your estimation needs to take place up front.  The company is asking you how much it will cost to build the application because they are unwilling to fund it forever.  They want it to end…….preferably sooner rather than later.  Funds are limited and your project, although perhaps necessary, is not viewed as critical to the company’s future.  Its ROI may even be negative.  Returning to the leadership of this company with the answer; “I’m not sure how long it will take….just fund the team for a year and we’ll see how it goes every iteration”  would be a mistake that would likely result in your dismissal.

In the 2nd scenario, if I told the team, after securing funding and hiring them, “we’re using scrum”: they’d estimate the work the next iteration. They would assume their estimates would be taken seriously and you’d give them time to complete the work as it unfolds regardless of whether their estimates fit your original project funding or not.  That’s only fair.  Unfortunately, that puts you as the manager in the uncomfortable position of submitting budget/schedule variances and/or cutting scope when you’re original estimate is proven to be inaccurate.  Hence, you’ve failed at managing the project and therefore…….”this agile thing doesn’t work”.

The mistake was to assume the company’s leadership understood and was organizationally committed to scrum and agile principles.  The mere fact that they are asking you to estimate the funding you’ll need to complete the project tells us otherwise.  If they had asked us, “How much does it cost to fund a software development team for the next 3 years?”  Then we’d be wise to approach it from an agile perspective.

The Real Problem

So, what is the real problem with agile adoption in organizations?  It can be boiled down to these points:

  • Agile assumes that the company wants a long term software development effort not a short term project.
  • Agile is often assumed by company leadership to be a development process with no impact on budgeting.  This is not the case.
  • Development teams assume leadership understands the implications of adopting agile at the budgetary level.

The complexity of these points can’t be underweighted.  Developers and development teams often have zero visibility into budgeting so they are unaware of how their agile efforts are being accounted for in monetary terms.  This is evident in so many agile articles on the web.  Likewise, management is often ignorant of development and specifically agile development practices.  Agile adoption requires education to ease the clash and misunderstanding of these two worlds.

So what are some of the consequences of attempting to adopt agile practices on a fixed bid project…essentially laying an agile façade over the waterfall project?

Story Points

Story points are often used on agile teams to determine the complexity of the work being done.  The number of points completed each iteration determines their velocity ( points per iteration ) and gives management an approximation on how much work can be completed in a given iteration.

If you come from a fixed bid shop like company Y your immediate question is, “How does this relate to hours?  How do I project costs and ROI?”  Truthfully, it doesn’t.  It isn’t intended to.  Again, the agilist is assuming you’re funding a software development team not a software development project.

In company X you could estimate things by hamburgers or cigarettes in each iteration.  It doesn’t matter.  You’re going to get the product done at some point ( +/-  functionality requested ).  The only real question is at what point to do we call it complete and release it to production.  Funding for the team is not contingent on estimation of effort.

In company Y project funding is directly related to estimation of effort.  It is critical that we tie this to time because our cost driver is often an hourly rate. Story points have no meaning here.

Scrum master vs PM

“Agile does away with the need for a project manager.”  Ever heard this before?  It’s scary for traditional PMs and unintentionally threatening.  However, it is correct.  If you assume that a team is funded year after year regardless of projected effort then the needs for organizing and managing the development effort are more centered on technical leadership, task and risk management.  Timelines and budgets go out the door. A scrum master is sufficient, preferable for getting the job done.

However, if you’re in a non-agile situation, like company Y….then traditional PM practices are not only valid, but essential to making sure the effort is kept within budgetary and schedule tolerances.  In this situation the leader of the development effort is being entrusted with precious company resources that can’t be wasted and needs to have the skills of a CEO-Lite.

A funded development team does change the project manager role.  A fixed bid project does not.

Daily Stand Up Meetings

Agile uses daily stand up meetings for a variety of reasons: motivation, risk mitigation, status, accountability, team building, etc.  It’s a good idea that is equally at home on a fixed bid waterfall project.  There is no reason this practice can’t continue to be used, but the team on that fixed bid effort has to realize that you’re not really doing agile and there is a deadline looming.  You also might want to weigh the time needs.  The daily stand ups should be short, but 15 minutes a day adds up when you only have 3 months of funding.

Iteration Reviews

With fully funded software teams that use agile the question of when something is done is answered incrementally.  Functionality is reviewed at the end of each iteration ( say 30 days ) and evaluated for readiness for production release.  Again, this is a good idea that could still be used in a fixed bid situation, but the business owners need to be coached to understand the iteration review as a risk mitigation and accountability technique and not a demonstration of the completed product.

Iteration Planning

Iteration planning really does assume you’re using agile in a team funded scenario.  It necessitates your costs are known and fixed for the budgetary cycle and that any estimates the team comes up with won’t play havoc with your budget.  Doing iteration planning in a fixed bid situation will almost certainly result in confusion, budget variances, and/or loss of functionality.

Burn Down Charts

Burn down charts show the progress of completing functionality in a given iteration.  They are a measure of team performance over time.  They do not illustrate how close the project is to completion.  If we were to sum all of them up…..they might show this, but given that they are usually used strictly for the development effort of a project; this won’t always be the case.

In fixed bid scenarios the question is not usually one of how much functionality the team is doing per time period.  It really doesn’t matter.  They need to get all the functionality done within the time frame that the money allows.

So using burn down charts and iterations in a fixed bid project sends the wrong signal to the team and your customers.

Summary

Firstly I would suggest that trying to adopt agile in a fixed bid scenario/project funded situation is not recommended.  Instead, as a manager, you should make the assessment of whether the company can support an agile practice/fully staffed development team through time.  If the company can; then you should use agile…it works well.  If the company can’t….then you’d be wise to stick with traditional project management practices.

If you determine that your company has the resources and the workload to support a software development effort but isn’t using agile then it comes down to convincing the leadership that agile makes sense for this effort.  Put on your change management and sales hats….you’ll need them.

Secondly, project manager and scrum master are not static roles and titles.  In one company a PM/SM may have budgetary responsibilities. In another they may not.  In some they may have direct reports in a traditional organizational structure.  In another the structure may be more matrixed and the PM/SM might have no direct reports.  I mention these differences because agile articles, like all writing, is written from the viewpoint of the author.  Too often what worked in one situation is attributed to being a superior process or technique…….when in actuality the organization and roles fit the process and technique.  Change the roles and organization and it might not work as well.  Context is often missing in the agile vs waterfall blogosphere.

Lastly, the agile debate is often likened to a philosophical war.  But from my experience and vantage the confusion is largely an outgrowth of misunderstanding.  Too often a technical manager hasn’t thought through the business implications of adopting agile.  Likewise business folks frequently misunderstand agile as being ‘some development thing’ with no relevance to how they just funded the effort.  I’ve been fortunate in my career to walk across the bridge of misunderstanding and see both sides.  Doing this has given me insight into the background budgetary assumptions that so frequently go unrecognized as the cause for agile adoption failure.