My latest news article on InfoQ -> http://www.infoq.com/news/2011/11/project-managers-problem
NEWS ITEM: Project Managers Creating Project Failure
Reply
Tag Archives: Agile adoption
How Will Tablets Impact Your IT Strategy?
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
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.
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.
The Bad Attitudes of Agile
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
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?
- How much will it cost to add this feature?
- How much will it cost to deliver release 2.1.0 ?
- 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.
Are You Commited?
Scrum Commitment Drama
So you’ve figured out team capacity, you’ve planned your iteration, and the scrum master looks around and asks everyone if they are willing to commit to the iteration. What does he mean? Is he referring to how many days you’ll be available to work during the iteration? Or is he referring to something deeper….an emotional state or pledge of some kind? How do your colleagues understand commitment? How about management and the business owner? It probably depends on what company you are working for, but more deeply….the answers seem to come in two flavors:
- commitment to complete the stories and tasks within the iteration time frame.
- commitment to *try* and complete the stories and tasks within the iteration time frame, but you’ll probably need to move some to the next iteration.
This nuance can’t be understated. Those of you working on scrum software development projects know what I mean. Colleague A is a realist and thinks commitment is putting in 8-10 hours a day and making every attempt to complete the work knowing he has a family and other commitments. Colleague B sees Colleague A as a slacker. Colleague B is a driven visionary that regularly puts in 10 hours or more per day and is willing to do ‘whatever it takes’ to get the iteration complete. He manifests himself through his work. So who’s right about commitment?
Your heart might swing you one way or another as you gravitate to the view that most closely mirrors your circumstances. But the point of this article is to weigh both and hopefully find some commonality that mitigates the drama and machinations around ‘commitment’.
Why is this important?
Misunderstanding the nature of the commitment to the iteration is a source of team tension and a potential sinkhole to productivity. Does it have to be? Probably not, but before I go too far I’d like to point out that it’s not just Scrum and Agile iterative planning that have this dysfunction. Rather, agile methodologies, with their open culture and self organizing, bring to the front what is often tucked neatly in the corporate closet.
Commitment – How do you define it?
A good question. And like many good questions it should be asked up front….in the interview. No one wants to walk into a job and find the level of commitment asked is not what they are willing to give. That’s fair, but this presumes the scrum team knows the answer, they’ve defined what commitment means for them. How many scrum teams can say they’ve done that? If you’re like most….the team is polarized by the two views first mentioned with shades of gray in between. So how do we define commitment to an iteration? What are some options so that when we ask during an interview; we know what we’re looking for.
Mission from God
This level of commitment isn’t for the faint of heart. When you joined this scrum team you signed with your own blood. All stories in an iteration “HAVE* to be completed….the velocity is law. No exceptions. Commitment here is a spiritual, emotional exercise in discipline and belief in the product. Seem crazy? Maybe. But before you dismiss it; there are industries and situations in which this completely makes sense. Some examples:
You’re at the absolute dark bleeding edge and trying to keep your technological advantage.
You’ve created a startup and money is not exactly flowing like water. To keep you’re funding you must deliver.
Heavy competition is driving the need to be first to market.
That’s the culture…..”it’s what we do.”
The drawbacks to this mode are known, but worth stating: burnout, setting up expectations you can’t sustain, and a work intensity that excludes many good candidates.
Time Bound
A less demanding road to commitment is the time bound agreement. It might work like this: We as a team agree to work between 40 and 50 hours a week and believe the stories in this iteration represent that time. For those who come from the “mission from god” shop this would be called a ‘union mentality’. However, it does have it’s place, and gives those with families, friends, and hobbies a chance to hang on to those commitments as well.
This team will ideally try to achieve their velocity each iteration, but has an open gate to move stories to next iteration if the team has met their time commitment. The drawbacks: Commitment in time, space is achieved, but not in spirit. Do those hours include lunch or not? What about smoke breaks? It gets nettlesome when you start counting the clock.
Stair Step
A more proactive response to managing your velocity and defining commitment is using a stair step model. It works like this:
- Team velocity is 40 story points.
- Iteration 1 the team commits to 35 story points. An easy iteration for them.
- Iteration 2 the team commits to 45 story points. Not easy, not hard.
- Iteration 3 the team commits to 55 story points. This is a stretch. They might make it ; they might not.
- Iteration 4 the go back to committing to 35 and repeat the stair step again.
This allows the team to proactively engage and manage their iterations; segmenting them into simple jogs, brisk runs, and marathons. The team then knows upfront that which iteration will be a tax on their personal life and whihc one will give them more freedom. Drawbacks: it sounds ideal but you’ll likely have folks find excuses to be ‘out of the office’ during the marathon iteration.
Grouping
This concept works well if you have multiple scrum teams. Here’s the scoop:
1. Team A’s velocity is 40 story points and their commitment is ‘Mission from god’.
2. Team B’s velocity is 28 story points and their commitment is ‘Stair Step’
3.Team C’s velocity is 20 story points and their commitment is ’40-45 hours a week’.
The advantages are obvious: new employees can fit into the organization regardless of their personal commitment levels, a tiered or group approach allows a team member to try on different levels of commitment, and those of like mind get to work together.
Drawbacks: requires a big software development project(s) and budget, competition/hostility might erupt between teams, and poor performers may gravitate to one team…giving that commitment level a bad name.
Leveling
Leveling is stair stepping by individuals. Team member A might put in a hard iteration this time. Team member B might put in an average effort. Team member C gets it easy this iteration. Next iteration they rotate roles.
Making the Decision
This is only a partial list of ways to address the commitment conundrum. Whatever choice is made; it won’t be perfect. Poor performers and top tier talent routinely clash. Objectively defining commitment is only half the battle. The other half is getting the team to follow through on that commitment. This comes down to solid leadership skills from your scrum master and others. A framework needs to be enforced if it is going to be effective, trusted and used by the team.
However, getting to an agreed commitment level is essential if you want your velocity to represent the optimized potential of your team.
Summary
Ultimately the scrum team’s goal should be to produce on a rate that is consistent with their potential. Making certain everyone understands and agrees to the commitment level up front removes a blocker before it manifests itself. Some may read this article and say, “Commitment is a function of story points. You let your team run a few iterations and gauge the average number of story points they can complete. That gives you your velocity…which forms the basis for your commitment.” There are two problems with this: the foot dragging team that ‘games’ the system and sets its velocity well below what it could do, and the perception of effort from those who are paying for the project.
In the first instance the team is composed of individuals who are less than honest for one reason or another. It is hard to know this up front, but if left unchecked your project will suffer financially and materially. Setting the tone and agreement up front takes away the possibility of misunderstanding the nature of the commitment and gives you a more solid understanding of how the velocity came to be.
In the second instance ,while the project may get done at a velocity level that is lower than what the team could achieve, the risk is that the product owner will feel they’ve been taken for a ride, and “this agile thing is a way for developers to goof off.” If your velocity is 40 story points but the team seems capable of taking a 2 hour lunch twice a week and doesn’t show up till 9am and leaves by 4pm; the commitment is going to be questioned. Dangerous? You bet. The options for fixing such a scenario are dire. So, to mitigate such a risk up front it behooves the scrum master to set and agree to a commitment level up front; making sure the product owner is in agreement.
Finally, human motivation and desire to do any task is not strictly limited to working agreements. If after agreeing on your commitment level; the scrum team still is not performing well then further investigation is warranted. An agreed commitment level puts lines and boundaries on the playing field; but your team’s willingness to win will be an alchemy of many variables.
Why Does Agile Adoption Fail In Some Organizations?
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.
Pragilematic 