Tag Archives: Software Development

The Agile Management Fad

Posted on by
3

Is Agile a management fad?  Is its blistering adoption throughout the world rooted in a proven value driven approach or the hysteria of the masses clamoring for a new trend to profit from and identify with?

Fad – defined

According to Wikipedia a management fad has certain characteristics. Let’s look through these defining elements and see if Agile can fit this definition.

1. New Jargon for Existing Business Processes?  Seems that there are plenty of examples that fit this like:

Manifesto = Mission

User Story = Requirement

Planning Poker = Estimating

Daily Scrum = Daily 15 minute meeting

Scrum Master = Coordinator/Facilitator with no authority.

2. External Consultants Who Specialize In the Implementation of the Fad. Would anyone deny that agile has these in abundance?  Agile consultants are everywhere and firms specializing in agility are in no short supply.

3. A certification or appraisal process performed by an external agency for a fee.  Yep. Many of these exist. Although they don’t all agree with one another on the merits for earning that certification, CSM, CSP, PMI-ACP, and the icAgile body of certifications represent a diversity of vehicles for achieving formal certification.

4. Amending the job titles of existing employees to include references to the fad.  There could be room for debate on this one, but a short search on monster.com or dice.com show a plethora of ‘agile project manager’ versus ‘project manager’ positions.   Equally, we’ve seen software developers that specialize in agile practices now called “ninjas” and there is the  “agile scrum coach” that now replaces the old title “application development manager”.

5. Claims of a measurable business improvement via measurement of a metric that is defined by the fad itself.  Velocity is the most prominent measure that comes to mind.  Further velocity is defined in increments the fad defines: story points.

6. An internal sponsoring department or individual that gains influence due to the fad’s implementation.  Organizational Agile Coaches, or an Agile Center of Excellence are two examples that have become common.

7.  Big words and complex phrases.  This one is kind of subjective, but YAGNI might quality. SolutionsIQ even published an agile glossary so you can keep up with all the terms & definitions.

Fad? Yes.  Value?  Yes.

So by this definition agile is, well,…a fad.   But does that mean agile practices have no value?  Here’s some of the things we’ve learned ( or re-learned ) from agility:

1.  Daily communication among team members really matters when the work is complex.

2.  The people doing the work must be accountable for it.  Don’t let them hide behind a project manager.  Let them take pride in what they do.

3.  Requirements require constant communication, clarification and understanding.  It’s a continuous phase communication cycle, not a document.

4.  Regular, timely feedback on work improves quality and job satisfaction.

5.  Teams need help coordinating, facilitating and communicating between themselves and others.

Agile’s popularity is still growing.  Clearly some of us see benefit even as the marketing machine twists agility into something it never really was or will ever be.  Like management fads before it ( Six Sigma, TQM, and CMMI ) agile has made an impact on how we create value.

Is there a cult following?  Of course.  Everyone likes being popular and making money.  But the end state of the agile bubble will be a reconciliation back to reality.  There’s no silver bullet.  Problems still exist and we’re never fast or perfect enough for the shareholders or customers.  Room for improvement is omnipresent.

Summary

The fever pitch of the fad is a beacon.  Full value has been realized, copied, marketed and redistributed without concern for the result.  While time exists and there is still competitive advantage…the crowd still gathers.  But, the drivers of innovation have long moved off the curve of agility, hybridizing and envisioning new methods and tools for further improvement.  Another wave will again crest and break onto the shores of software management and leadership bringing the promise of ultimate productivity and quality, but delivering only incremental improvement.

Advertisement

A Caboodle of Pragilematic Posts

Posted on by
Reply

I’ve been hanging out and posting at the ASPE SDLC blog.  Yes…I have their permission to do that.  Geesh.  Check em out Gilbert:

Six Things To Avoid When Reporting Project Status – Project status is about the facts and your strategy to address and manage those facts.

This Daily Standup Is a Joke – This article details some challenges associated with daily stand-ups and some potential strategies for dealing with these.

An Axiom of Project Success –  What’s the common thread to project success?  We’ve seen projects that should have died.  We’ve also seen projects fall apart that seemed like they were in the bag.  This post attempts to nail the overriding factor.

That’s Great…But How Does Agile Benefit Our Shareholders?  – Selling agile to key leaders in your organization takes more than just a thorough understanding of story points, and time-boxing.  This post brings it home for those wanting  a bigger bang for their agile swang.  Whatever that means.

The Root Cause of Water-Scrum-Fall

Posted on by
5

Introduction

Water-Scrum-Fall is the norm in many organizations today.  Despite the attempts of scrum coaches and consultants, the weeds of waterfall grow back into the agile garden.  What causes this?  This article looks at the root cause for the water-scrum-fall phenomenon and makes a suggestion about how to address it.

The Root Cause

Water-scrum-fall’s reality is not the result of people being unwilling to adopt scrum.  It’s not the result of a lack of passion for agile processes and practices.  Nor is it caused by a lack of executive support.  The cause?

Capital budgeting

In companies that produce software for internal use water-scrum-fall finds it’s greatest adoption.  Internally used software is strictly accounted for by the regulations in SOP98-1 and this financial machinery is what guides the need to plan up front.

Capital projects are investments.  To determine an investment’s return you need to know the estimated initial cost, and estimated revenue ( or savings ) the project will create.  These things are estimated up front so that a decision can be made on whether or not to pursue the investment.  The up-front nature of capital budgeting compliments waterfall and BDUF. It is a core financial business process guided and regulated by FASB.  Think about that for a moment…and then read on.

Scrum practitioners run up against a wall with capital budgeting.  It doesn’t fit their operational practice for developing software.  Under scrum….we shouldn’t be designing, estimating and crafting the project up front.  Instead we should approach it incrementally.  The problem with this? It ignores how enterprise software development projects ( capital investments  ) are funded.  The result is that everyone compromises and innovates.  Water-Scrum-Fall is the child of this compromise.

The Challenge

Scrum and other agile practices pose a challenge to enterprise software development efforts and the capital budgeting process.  Indirectly they say “Why are we funding this as a capital investment?  It’s not.  It’s an ongoing operational cost and should be accounted for that way.  If we don’t plan on funding this software development effort for the long haul…then why are we doing it?”  Funding a software development effort as an operational expense, as is done within software companies, does fit the scrum operational practice better.  But again…the difference between a software development effort being labeled CAPEX or OPEX is guided by FASB.  It’s not up to the company.

How Do We Fix Water-Scrum-Fall?

I don’t think there’s a silver bullet here.  But in my last article, Is There a Better Way to Estimate Capital Projects? , I threw out a suggestion for how to estimate a capital investment using tolerances.  This bypasses the need for an up-front detailed analysis of what the the LOE ( Level of Effort ) would be for the project, but still gets the business what it needs: an initial funding point and resulting NPV that augments decision making.

Summary

So water-scrum-fall is a pragmatic reaction by agilists and IT professionals to work with the business and its financial processes.  Did the originators of scrum not understand the capital budgeting process?  Were they oblivious to the financial architecture of the businesses around them?  Maybe…but to their credit; they weren’t trying to address this.  Their focus was on how to do software in an adaptive fashion so that it more organically addressed the operational realities of manifesting a complex vision.

What Techniques Do You Use Most To Deliver?

Posted on by
Reply

The poll is multiple choice, and you can add your own too.

Predictive *AND* Adaptive Planning

Posted on by
1

Introduction

If you’ve managed projects for any length of time you understand the truth.  It’s almost never the case that a project is completely predictive ( waterfall ) or completely adaptive ( agile ).  It’s a mix.  There are needs for both in any project.  Those project managers, companies, and consultancies that integrate both approaches into their project management efforts are hybridizing the agile movement and shaping the reality of the future.  Let’s look at some examples that are well known, visible, historical and outside the IT market.  Why?  I want to defuse the agile vs waterfall debate for a moment and abstract things away from technology to help us see the broader picture.

Example 1: Lewis & Clark Expedition

The expedition by Lewis and Clark to navigate the Missouri River and map the western territories was an immense, RISKY, long term project entertained by a focused project team of professionals.  This is a startup.  Their goal was to map a water born ( river ) path to the Pacific Ocean.  To accomplish this goal some level up front planning was required.  You simply couldn’t plop two guys down in St. Louis and say: “For the next two weeks go up the Missouri River, then have a retrospective on what you learned, share that learning with your sponsor in Washington D.C. and plan for the next two weeks of river navigation.”

Lewis & Clark needed supplies, people who knew the land, logistical expertise, some plan up front to start the mission. But while an up front plan was necessary, much was not known.  This is where adaptive planning comes in.  They would need to adapt as maps, events, and people turned out to be unreliable or poorly understood: winters were more severe, the Missouri didn’t go all the way to the Pacific and great Mountain chain blocked their path to the ocean, and accidentally injuries and sickness delayed progress.

While not having an up front plan could have delayed and increased the cost of their project…not being able to adapt along the way would have killed it.  It was an experiment, a gamble, and to make it work required flexibility and persistence.

Standish group would have called Lewis & Clark a failure because they exceeded their baseline schedule.

Example 2:  Apollo missions to the moon.

The missions to land men on the moon and safely return them during the late 1960s and early 1970s in the United States were massive projects of unknown risk and horrible complexity.  Failure would bring down a nation and a philosophy ( democratic freedom).  They closely mirror big ERP implementations or suitably large custom software development efforts in Fortune 500 businesses today.

Could these have succeeded without predictive planning?  It’s hard to imagine they would have.  There were so many variables and unknowns that were required to be nailed down before implementation to ensure success.  In fact, predictive planning to the Nth degree is what made this possible and successful.  Accounting for every risk, having a mitigation plan for every risk, and carefully coordinating all the sub-projects to the common goal would have been hard to accomplish via strict adaptive planning.

This isn’t to say that adaptive planning didn’t play a role in adjusting and dealing with risks/issues along the way ( think Apollo 13 ), but this project was almost completely predictive by necessity at the top-level.  There was too much at stake ( human life and a nation’s perceived status in the world ).

Even though the Apollo moon missions proved to the world that the U.S. was the preeminent technology leader vs the U.S.S.R  and would be revered for decades to come….this project, using Standish’s metrics, would have been deemed ——-> FAIL.

Example 3: Building a Table in Garage with Your Woodworking Equipment.

A more personal, and human project…building a table is something that’s been done many times in the past.  This is like building a new e-commerce site for a company.  It’s been done before, they could have just bought a vended product, but for some business reason they want to build their own.

Ok, since it’s been done before there’s a pattern, and we borrow from it.  We download the diagram, purchase our materials, and define our plan.  This is predictive.  As we begin to execute we discover flaws in the plan or the procurement process.  Wrong nails were purchased or the leg supports were cut too small.   These events require us to adapt.

After building the table we’d dust off our hands and say “Wow, that’s a little over budget and it took some extra time, but I got what I wanted.”   We’d call it a success.  Standish would call it a failure.

More?

I could go on.  What about Michelangelo’s works?  How about building the Dubai Tower?  Great human efforts ( projects ) are vision building.  Successful completion and delivery requires a range of approaches and a commitment to the end goal.

Summary

Hopefully you can visualize the adaptive *AND* predictive elements in these projects.  It wasn’t one or the other.  It was a gradient.  That’s where the present is and the future will continue to be.  Hybridization is good.  It isn’t about agile vs waterfall. It’s about achievement, belief, and success.

Development Shop Productivity – Should You Outsource?

Posted on by
2

Introduction

CIOs, executives and development managers will find the most interest in this article.  We’ll focus on a productivity measure for custom software development and how it may help you justify outsourcing your software development shop.

The Problem

How do you justify outsourcing your development shop when you know the immediate cost savings may not be there?  The trend toward mega-software development outsourcing shops isn’t slowing down.  But the gains to Fortune 500 enterprises are not always immediate.  You’re gut says it to you every day:  “It’s better to let someone else do this.  We just aren’t good at developing our own systems.  The bugs, the time, the bad requirements…”  But, how do you justify your gut?

A Formula to Measure Your Progress

I’ll skip past all the BS on the benefits and costs of outsourcing.  You can look these up with Gartner, About.com or some independent analyst’s site.  What I will present is a new formula for measuring your custom development shop value and tracking it relative to an outsourced effort.

Here’s the formula:

Custom Development Value Added = CDVA
Capital Dollars Invested = C
Operating Dollars Invested = O
Return on Investment from any completed projects  = NPV
Hours spent gathering & defining requirments = ReqH
Hours spent fixing bugs = BugH
Hours spent addressing help desk tickets = TickH
Hours invested in training = TrainH
Hours of Time Off = OffH

CDVA = ((C + O) - NPV ) / (( ReqH + BugH + TickH ) - ( TrainH + OffH ))

Let’s talk through it.  CDVA is your development shop’s productivity. The first thing you’ll want to do is baseline this for your current shop over a year and then determine how it compares to any outsourcer’s proposal.

The numerator in the equation represents your financial investment in custom development.  The denominator represents labor expended relative to this investment.

So over time you want to see your CDVA increase regardless of your outsourcing decision.  If the trend goes down or stays stagnant then it’s time to seek improvement.  There are some diminishing returns here, and you may need to make periodic investments to see greater value added later on.  But the point should be clear; we’re measuring the return on our development shop’s productivity overall….rather than on a project by project basis ( which can be very misleading ).

You determine the periodicity, but measuring this at every fiscal month makes sense to my inner accountant.

You might ask why I chose measuring hours around bugs, requirements, and trouble tickets and not the overall development effort? Well….experience tells me these are the areas with the greatest variability and also the areas where expertise and experience shine.  Those who are good at software and application development can do so with minimal bugs, less requirements analysis and their end product typically needs very little support ( I can see some CIOs smiling right now ).

Summary

Outsourcing is like any business venture and may require some upfront investment to see returns over time.  But, while this is intuitive it isn’t always measured in a consistent way that takes account of key development metrics like bug counts, support tickets, and requirements time.  Hopefully this article presents a way to do just that.  Enterprise IT is under increasing cost pressures and given the historical waste and loss associated with custom application development it only makes sense to look at outsourcing vendors who have the focus, experience, expertise, and clout to deliver.  Now IT executives may have a measure to justify and track that or at least show their shop is improving.  😉

How Will Tablets Impact Your IT Strategy?

Posted on by
1

Introduction

Gartner recently unveiled the top trends that enterprise IT should be strategically focused on.  One of those is the growing use of tablets in the work environment.   This post will take a look at the implications of increased tablet and smart phone use in the enterprise and hopefully deliver some insight into this trend beyond just a capacity replacement strategy for PCs and laptops.

Implications of Tablets and Smart Phones in the Enterprise

Let’s skip the obvious background and trend information and launch straight into the implications.

1. Printer exit strategy – Think of tablets as electronic paper.  That’s one of their utilities. Plenty of technology gurus have struggled to manifest using technology in lieu of paper only to be vexed by the utility, versatility and permanence of the 8.5 X 11 parchment of industry. So what’s different this time?  Portability, usability and eventually….sharing.  Right now it’s a little cumbersome to share notes, reports, and other virtual-papyrus artifacts with everyone in a room.  It’d be nice if my tablet recognized all those other tablets in the meeting auto-magic-ally and allowed me to share documents with them with little more than a button click.  A kind of permanent “LiveMeeting” or “WebEx” with RFID/GPS type sensory to recognize my location relative to the meeting schedule for that room.  It’s not there yet, but you can see it coming.

That alone won’t shut down your printers and get rid of the reams of stock in your office closet. Nor will it stop “Ed” at IKON solutions from frequenting your micro printing press to unclog the jam of a decade.  It will take you, the CIO, pushing, selling and implementing a bold strategy:  get rid of them.  All of them.  I’m talking about your printers.  People won’t stop using printers unless they’re gone.  Once they’re out of reach….they’ll find, and use the alternatives.

If you’re Hewlett Packard or Lexmark,  yesterday would have be a very good time to rethink your business model.  Kodak is foreshadowing you.  Tablets will get thinner, more collaborative, increasingly better at power utilization, and super cheap.

2. Embrace video/audio recording – Does anyone else see the paradox in someone with a tablet typing or writing meeting notes on his device when it’s fully capable of recording the visual/audio representation of that discussion?  Tablets and other devices can transform how your organization captures information and knowledge and shares that with others.  Written/readable documents don’t go away, but moving an organization toward a video/audio strategy should improve the quality of your work.  So much context is lost in written notes, documents, requirements, and emails.  How much does that quality cost?

Go with this strategy and here’s what changes:

  • A premium on presentation and verbal communication skills becomes essential.
  • This strategy augments your move to paperless ( number one above )
  • You need more storage and network bandwidth to capture all the videos / photos / audios:  think cloud here.
  • A tool to version, track and search this knowledge will be essential.  A wiki makes an ideal candidate.
  • Digital video and editing skills are now a key requisite on resumes.
  • Corporate policies need to be rewritten.
  • You might want to invest in pico projectors for everyone, but I think eventually tablet and laptop makers will make this a standard feature.

3. From office to work lounge –  Look at your desk/cubicle.  If you’re mobile and paperless…why do you need this space?   Work places are still relevant.  Collaboration and communication happen best in a common physical environment.  Working from home is like working in a really thick cubicle.  But to encourage the freedom and interaction that mobility and paperless bring to the office, the furniture and interior should be living, playful and open.  Many employers have already made this move:  mobile whiteboards, open touch down areas, couches, plants, and open space with lots of natural air are some of the interior elements that seem to work well for a work lounge.

The implication of work lounges and the increased interaction is that work is not work anymore.  People aren’t laborers, they’re….well….people.   Work, fun,  friends, co-workers, ideas, and profits will begin to blend.  This poses some challenges to stodgy HR policies and Tayloristic views of management.  Those who’ll succeed in this environment will be leaders, not managers and the org chart will flow around them in an organic way.   Corporate empire builders beware.

4. Office supplies / telecommunication equipment reduction –  In addition to dropping your printers and paper supplies you can now chuck your sticky notes, paper clips,  desk phones, and almost everything else in that closet.   Again, if you keep it around people will use it.  If you dump it, then they’ll get creative and use the tools they have.  Force the change.  Be the leader and save the company money.

Office Depot, Staples and others should plan their exit strategy.  Maybe they begin selling the work lounge concept and the supplies for that.  To date, I see little evidence they *get* this.

5. Killer App Coming……Plan for it -> Intersection of Identity / NFC – An earthquake is coming to the landscape of identity and access management.  Check out my earlier articles on this for background.  Your mobile device is an abstraction of you.  People will come into your employment with their credentials and data already digitized and ready to be transferred and used in your environment.  You’ll pull this data from LinkedIn, Facebook or Google+…….and using those same tools you can give them rights/permissions to systems on your cloud.    Kaboom!

In time this destroys internal LDAP systems, multiple id and password issues,  corporate HR systems and physical security access control.  These will be thrown into a social mobile nfc blender and become the domain of mega vendors.   The tech war to control the identity market will have no comparison to previous epic battles.  Those who scale this out will capture the lucrative enterprise IT market.

The implications are vast and will touch every corner of the enterprise IT market.  Plan for this NFC hurricane to shake out vendors through 2012-2013.   You’ll want to embrace those software vendors that do NFC, cloud and social identities for access.  My prediction?  Microsoft’s collapse is right around the corner.

6. Build vs Buy vs…….Download for Free.  The implication of app markets is that you now have a third generic system strategy:  download for free.   Any options analysis for system planning should consider this.   While it hasn’t happened yet, that i know of, we could well see a big vendor crash as a freely available mobile app does the approximate functionality for none of the cost.

The download for free option should also be used as a development strategy.  Maybe you find something that ‘kind of meets’ your needs.  Download, play, experiment, trial and get a feel for it.   Then, approach the developers of that app and say you have some ideas to improve it.  They might do it for free.

App markets are consumerization of IT writ large.  Our work force will be our IT department, and our IT department will turn into technology strategists, gurus, enterprise architects.  High caliber, well paid business technology talent will replace the ‘system analysts’ of today and IT departments will shrink.  Invest in your best.

7. Email’s days are numbered – Email gave us a huge productivity boost in the 90s.  Indeed it was the killer app of the first internet explosion.  But as we’ve moved through time its weaknesses are costing us.  The loss of context in email, as apposed to physical presence undermines quality of work.   Mis-understandings, multiple interpretation, cultural differences and poor writing lead to *email threads* that are a semiphore of poor quality.  Think ,just for a second, how many issues you deal with daily that revolve around clarifying what someone meant in a cetain email?   It’s astounding and it’s holding us all back.

There’s a better way, but it hasn’t been built yet.  Google’s Wave initiative is a bold attempt at remaking communications tools.   It’s close, but the email replacement will incorporate the cameras, microphones, and NFC chips that are built into tablets and smart devices.

Any CIO will want to watch this space and price out the latent, untapped potential cost savings in boosting communications quality across the enterprise.  Combine this vision with implication #5 above, and you can see the scale of change coming towards us.

8. POS industry: look out you’re about to be remade –  Tablets can be turned into POS terminals.  Enough said.  If you’re a POS vendor and you don’t realize this: what in the name of clam chowder have you been doing the last 2 years?  With NFC in 2012 an avalanche of slim, mobile terminals will usher in tap-pay while still accepting swipe pay.

Cash and checks will be digitized too and while the exact shakeout is still fuzzy to me; private digital currencies ( Ven, BitCoins ) are going to play a role here.  As I professed in my article about the externet ( internet of things ), the combination of an amorphous, unaccountable virtual world and the ability to pay with a tap lower and free the barriers to entry for those enterprising enough to believe they can challenge the global fiat currency oligarchy.  Nation states, banks, and the overlords of international finance will surely capitalize on this opportunity in some way.  Watch my blog for future posts on this….I’m still noodling on it.

9. Healthcare – Goodbye clipboard, hello iPad.  It’s all over the place, and doctors and nurses are demanding that all their software tools run on tablets.  FINALLY technology understands healthcare’s unique needs.  God bless Steve Jobs and the Apple-neers.  Steve, this was truly your greatest gift to the world…..not the iPhone.   You’ve given doctors a tool that will help them treat and solve the very problem that took you from us too early.  Rest in peace.

Taking this further, digitizing medical records and sharing that with patients is the bonfire lit by the meaningful use regulations passed in 2009.  NFC, smart devices and tablets will make the sharing part real time and collaborative.  People will really know and understand their health.

Summary

Surfing the waves of enterprise tablet integration has great possibility for the visionary C-level executive.  Will you be one of them?   My consultation to you:  tear up your current IT strategy document and vest your talent with the authority and energy to make these nine implications happen.   If you don’t…your competitors will.  You can be sure that some of the finest minds in IT are reading and following this blog.  Numbers don’t lie.  Be part of the revolution rather than a victim of it.

I’m Skeptical on Agile – Sell Me

Posted on by
2

Introduction

This article will address a common reaction to those presented with the possibility of adopting agile in their enterprise: skepticism.  CIOs, application development managers, directors, and senior architects will glean the greatest insight from this but development professionals and project managers will find interest too.

On Being Skeptical

As a software professional your skepticism is not necessarily misplaced. There are plenty of agile coaches in the market today professing to deliver faster, better, and cheaper on a regular basis.  Their message is honey in the ears of the right executive.  It becomes even sweeter when you consider the economic climate that many businesses are facing today.  There is opportunism here and it would be well advised to vet any agile coach.

How do I know an agile coach is worth the money?

I’ve devised a simple matrix ( below ) to help guide one in validating an agile coach.

Weight Coach 1 Coach 2 Coach 3 Coach 1 Score Coach 2 Score Coach 3 Score
Number of Projects Managed 3 2 17 3 6 51 9
Years of experience in SD/AD 2 5 24 7 10 48 14
Highest Budget Management Experience ( 1 = true, 0 = false ) 1 1 1 0 1 1 0
Number of References Validated 3 3 8 1 9 24 3
CSM Certification ( 1 = true , 0 = false ) 1 1 1 1 1 1 1
PMP Certification ( 1 = true , 0 = false ) 1 0 1 1 0 1 1
FINAL SCORE



27 126 28

So let’s talk through this matrix a bit.  First, I give pretty heavy weighting to experience here.  In truth we’re not just looking for an agile coach we’re looking for someone with the battle scars of being in the AD/SD world and knowing when and where agile works vs more predictive methods.

We also want to know that they’ve actually implemented agile methods in other places hence the need for validating references.  The key word here is “implemented”.  There are plenty of folks who can regurgitate the agile manifesto and paraphrase the thinking of leading agile theorists, but agile coaches should show a track record of making it happen.

Budgetary management experience, in my opinion, is essential.  If they haven’t managed the dollars/euros/yen around a capital project ( or operating costs ) then they may have a very misguided notion of why projects succeed or fail.   The CSM or PMP who was merely accountable for a timeline with only a misty concept of how it related to money is ill-equipped to profess a transformation of your SDLC process.  Why?  Agile techniques profess delivering software in iterative cycles ( every 2 weeks ).  If some level of requirements aren’t complete by the end of each iteration you have two options on a fixed bid capital effort:

  • Don’t do that functionality.
  • Postpone it until you do have the capital available.

This sounds fine in theory, but the truth is that every system has some minimal set of requirements that must be completed for the software to be functionally usable.  If the money runs about before the agile projects succeeds in delivering this minimal functionality then your project will be seen as a failure.

Certifications show learning of theory.  I weight them low, but still think its practical to have these ( Certified Scrum Master and Project Management Professional ) if an agile coach is selling himself as a professional in software development delivery.  They should understand and know agile as well as more traditional management concepts and techniques.

Lastly, you should realize that agile adoption is not just a function of the agile coach.  The organization needs to be willing and able to accept the changes agility will introduce.

But my current process works, so why should I switch to agile?

If you have a working process and there is no immediate need to push you to agile then you should take the time to map out a strategy for your development shop.  Agile can be beneficial and Ryan Martens at RallySoft does a decent job of articulating when agile methods can benefit a development project.  His rendition of the Uncertainty vs Complexity diagram proposed in Stand Back and Deliver gives an AD manager a basic tool for plotting his/her projects along these two broad metrics.

project-types

What are the benefits if agile is applied to the right type of projects?

Better Risk Mitigation – Agile methods emphasize iterative delivery of software.  A standard cadence and check point to the project sponsors allows for defects, requirements misunderstanding, and general issues surrounding the effort to be mitigated on a timely basis.  Couple this with a daily stand up meeting where team members determine how to resolve issues and coordinate work and risks to the development effort are generally better managed.

Testing starts earlier – Agile development emphasizes vertically slicing your application and developing functionality incrementally.  This is a technical challenge, but assuming the development team can tier the system architecture this way, then your testers can usually start functional testing much earlier in the development cycle.

Increased Sponsor Satisfaction – Project sponsors are involved routinely through agile.  The developers have a direct line to the customers.  This continuous feedback loop usually leads to better communication and understanding between the team and customer.

Stronger Team Accountability – It takes time, but as the team culture shifts from command and control to a collaborative effort where developers take responsibility, collectively, for their work; the team begins to see how their efforts help/hinder the project.   An adjunct to this is an increased sense of pride in their work and kinship with each other.

What do I need to watch out for when adopting agile?

Cultural Shift – This can’t be under weighted.  Agile places greater emphasis on the team managing itself and its day to day activities. Subtly, agile preaches two things:

1. Development team and customer working together.  Meaning other managers and IT leadership have a de-emphasized role.  Your risking attrition by some of your better players if you ignore this.  Proper coaching and preparation for this change and its effect on roles and responsibilities is essential.

2. Team stepping up and coordinating activities among it’s members.  This is normally done by a PM or Dev manager or even a senior technical leader.  Some methodologies, like Scrum, emphasize a new role ( scrum master ) to take on the facilitation aspects.  For developers unaccustomed or uncomfortable with organizing and planning this may be difficult.

“Documentation is not needed”  – You may hear this from some agile coaches and theorists.  The original agile manifesto emphasizes working code over documentation, but as a development professional you’ll need to decide if this really makes sense  for your project.   Some of us have regulatory and legal reasons for documentation.

Dogmatic Views – I wrote about some of this in Bad Attitudes of Agile, but some team members will see agile as a very strict set of practices and may twist the theories and methodologies to suit their own ends.  By its very description agile is meant to be a flexible approach to software and application development not a rigid set of rules that cannot be altered.  There are the pragmatic agilists and then there are the agile zealots.  Watch out for the latter.

Summary

Benefits can accrue from agile methods.  These benefits, for the right projects, should result in better quality, reduced cost and schedule variance associated with requirements misunderstanding and defect management, and a more complimentary relationship with your customers.  As mentioned earlier skepticism is not misplaced, but by looking for an opportune experimental project to introduce agile a development manager can assess its applicability for his/her shop.

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.