Designing and Developing Cross-Cutting Features
Every developer has had to integrate with another system, API or component. Tis article provides strategies to handle the change and for he separating system boundaries.
Article
The content has been bookmarked!
There was an error bookmarking this content! Please retry.
Is Agile Sub-Optimal?
Posted by Terry Bunio on Dec 05, 2011
As I review proposals from people in the Agile community to push the boundaries of Agile, I believe that Agile is in danger of becoming more and more Sub-Optimal.
RelatedVendorContent
Five Key Practices to Agile ALM
Agile Practices to Improve Project Management Organization (PMO) Effectiveness
Agile Maturity Model Applied to Building and Releasing Software
Agile assessments for your team
Related Sponsor
Maximize your business-responsiveness with Mingle. Provide your global development team a shared space that adapts to the way they work.
Before I proceed, let me just review my definition of Optimal and Sub-Optimal Systems:
“An Optimal system is a system where the optimization of the system or the elimination of waste has been undertaken based upon the value stream of the entire system”
“A Sub Optimal system is a system where the optimization of the system or the elimination of waste has been undertaken based upon the value stream of part of the system. These efforts may actually cause the entire system to be less efficient”
Project Value Stream
Agile has rightly focused on the Project Value Stream and I don’t believe anyone would argue that the Project Value Stream is maximized when executing the project in an Agile manner. But by optimizing ONLY the Project Value Stream, have we sacrificed other Value Streams?
What about the value external to the project? What about the Program and Company value?
Program Value Stream
If I follow Agile by the consensus of opinions I hear proposed most frequently, the following two types of project information are lacking:
Project Memory – Information about how the project was planned and executed.
Solution Memory – Information about the technical or functional solution for the project.
If I use User Stories on stickies, manage via a KanBan board, and my retrospectives, application and automated test cases are primarily my documentation at the end, can I answer the following questions?
- How can I search prior projects for leverage opportunities? Must I read through the code and tests and somehow determine leverage opportunities?
- How can I review prior projects history for a history of how estimating worked so my estimates can be better this time?
- Since we acknowledge that I there is never enough time to create all the automated test cases, how do I know if a new requested change is implementing behaviour that is beyond the intent of the application and will cause downstream effects that I can't anticipate because we don't have an automated test to ensure its correctness currently.
- How can I ensure my solutions are consistent across projects if they don't have high level knowledge of each other?
- Do I have adequate documentation to maintain these applications for the next 10 years if I have a complete turnover in employees?
- How can I manage a department where the reality is that many people will not be able to be dedicated for the lifetime of the project? Do I require more documentation in a situation like this?
By it’s very nature, Agile Software Development projects are silo-ed projects with primarily full-time members and with little governance breaking down the barriers between projects. This causes an even greater need for attention to the Program Value Stream.
Company Value Stream
Perhaps one of the most troubling trends lately is the statement that estimates should not be created anymore as they are bound to be wrong and a waste of time. It is proposed that the project should be started and after two or three iterations the project will be able to confirm the velocity and inform the client as to an accurate estimate on what it will take to complete the project.
This statement is from the point of view of the project entirely. Every project that starts needs to be backed with a business case that confirms that for $X I will return value Y and that is acceptable to the business. If we are not estimating projects anymore, we run the risk of initiating the wrong projects and wasting project money until we determine that the project will either spend too much money or return too little value.
Stating we don’t need to estimate is ludicrous if we truly care about the long-term viability of the company. Implied in my statement is my belief that User Story Points must be translated to hours. In discussions I have had with developers, they have asked for the hours for each User Story as a means for ensuring they were on track. (when I didn’t provide it, they did the math themselves)
Although I like the use of User Stories and User Story Points to estimate, if we do not translate the User Story Points to hours we are Sub-Optimizing. We are placing the development process ahead of meeting the business case. By not giving the developers the context of the estimates in relation to the project’s business case, we are creating a layer of isolation between the business case and the programmers. We are making the project iterations more efficient, but also possibly sacrificing the ability to meet the business case.
And isn’t the business case the reason the project exists?
Three ways to ensure your Agile Project is not Sub-Optimal
- Estimate your project – Make sure you estimate your project and ensure that estimate is incorporated into the Business Case to validate the project raison d’etre. These estimates must be given the care and attention they deserve and not just estimates for the sake of getting the project approved. My recommendation for how to estimate an Agile project is a topic for another day.
- Create Lightweight Solution Architecture Deliverables – Ensure that your project defines the Solution Architecture at a high level and everyone shares that vision of the solution. These deliverables can then be used for project governance and for ensuring consistency and leverage opportunities across projects in a program.
- Translate User Story estimates to hours and track your time – User Stories being translated to hours sets the duration expectation with developers and also provides context back to the business case to ensure we are on track. Tracking time, the bane of everyone’s daily work life actually does have great value for the program and company. Although knowing a project velocity is a great predictor and planning tool, it doesn’t let me know the following:
- What types of work do we estimate poorly or take longer than expected?
- What types of work do we estimate well or take less time than expected?
- What types of work do we forget to estimate?
- What issues do we encounter that add to the time in take to complete a task?
Summary
"Are we sacrificing long-term Enterprise objectives by developing projects in an Agile way?" I don't believe that anyone argues that Agile is not the best way to execute a project. But I do think that sometimes Agile's sole focus on value for the project and the client within the project may cause us to lose focus on the value the Program and the Company requires.
We need to ensure we keep the entire value stream in mind when we are optimizing processes. Otherwise we will have a string of very successful projects at a number of failed companies.
About the Author
Terry Bunio is currently a Principal Consultant at Protegra. Terry never wanted to be a Project Manager. His main career has been in Data Architecture. Along the way Terry discovered that he enjoys helping to build teams, grow client trust, encourage individual growth, doing project work, and helping to guide solutions. It seems that some people like to call that Project Management. As a practical Project Manager, Terry is known to challenge assumptions and strike the balance between the theoretical book agile and the real world approaches. Terry is committed to Agile implemented according to Lean Principles.
- This article is part of a featured topic series on Agile Techniques and also Agile
- See more Agile Techniques content at: http://www.infoq.com/agile_techniques
- See more Agile content at: http://www.infoq.com/agile
- Other recent content items in this topic
Good read
by
Razvan Radulian
Posted
Eh?
by
Robert Barth
Posted
Re: Eh?
by
Terry Bunio
Posted
Re: Eh?
by
Assaf Stone
Posted
Re: Eh?
by
Terry Bunio
Posted
Re: Eh?
by
James Watson
Posted
Re: Eh?
by
Terry Bunio
Posted
Concerning
by
Andrew Rusling
Posted
Re: Concerning
by
Terry Bunio
Posted
Re: Concerning
by
Andrew Rusling
Posted
Re: Concerning
by
Terry Bunio
Posted
Muddled Logic
by
Frank Krasicki
Posted
Re: Muddled Logic
by
Terry Bunio
Posted
Re: Muddled Logic
by
Frank Krasicki
Posted
Re: Muddled Logic
by
Terry Bunio
Posted
Where to start?
by
Mike Burrows
Posted
Re: Where to start?
by
Terry Bunio
Posted
Create your story cards a better way
by
alex keenan
Posted
Re: Create your story cards a better way
by
Terry Bunio
Posted
Estimate Well, Estimate Poorly
by
robert pryde
Posted
-
Let's not forget:
(1) being agile > doing Agile
(2) effective/efficient (agile) planning & estimation are critical in Agile (even much more than in any other non-Agile ways... despite various false beliefs)!
Just my 7 cents,
Razvan:-) -
"Every project that starts needs to be backed with a business case that confirms that for $X I will return value Y and that is acceptable to the business"
If you haven't done any work, and therefore your estimate can be off anywhere from 10 to 500%, then what value are you getting from doing the estimate that early? Just so you can answer this question? You will need to settle on some (fake) estimate to answer that question with a single value (which is what the people with the purse strings are going to want). Which do you choose? 10% 500%? Something in the middle? The simple fact is that that question cannot be answered with any fidelity because not enough information is known... once again, we're trying to predict the future, which humans are notoriously bad at.
And what's the point? If the project is a two-year long thing, if you're truly agile, you may not even be building the same thing six months down the road, so who cares how much it's going to cost? Does the company need the functionality? Does the client want the functionality? Break the thing into much smaller pieces and deliver those incrementally -- the questions regarding "is this cost-effective" answer themselves after a short period of only a month or two. It is not a failure of agile to cancel a project that has been determined to have a garbage ROI.
Generally, for some really new idea, you can't figure out if it's going to make you any money if you don't try it out and see what happens. For everything else, it's already been done, so just buy it from someone else. -
I agree with much of what you say Robert.
I agree that we should break large projects into increments and smaller projects so that have a smaller feedback loop and we are delivering what the client wants. Sometimes the client and we don't know in detail what the final result will be until we are down the road somewhat. But I believe we should know what the solution needs to achieve, but maybe not all the how. At a high level we should know the solution and if we know that we should be able to have a good estimate.
Now this does not apply for truly novel and new solutions. If there is a lot of research and investigation required, then it will be next to impossible to create good estimates. I would estimate that less than 10% of projects fall into this category though. This extreme case does not mean we should not attempt to estimate the other 90%.
I do think that you can do some work to envision the solution to make your estimates more accurate and validate the business case. This can be done by using multiple estimating techniques, reviewing past actuals, and using a preliminary Rapid Discovery Event for the entire solution before you start on iterations.
But I guess the one quote you mentioned that stuck with me was: "It is not a failure of agile to cancel a project that has been determined to have a garbage ROI." I disagree. I think it is the failure of Agile to cancel a project with a garbage ROI if Agile recommended to start the project without an estimate because it was impossible to estimate whether the Minimum Viable Product could likely be created for an acceptable cost. -
Terry,
I agree that it is important to optimise the whole system, not parts of the system. Having directly seen the negative effects that this can have, I am constantly looking out to the ‘whole’ as much as possible.
It is important (and usually a requirement) to establish a business case to get the go ahead for a project. My usual approach is to combine Robert’s and your ideas:
1. Guestimate the project prior to starting to provide the estimates for the business case.
2. Complete the first couple of iterations focusing on understanding the risky parts and proving the architecture.
3. Cancel the project early if it is not on track to achieve its ROI.
The next steps beyond this are to establish an agile Project Management Office, so that they can optimise spending over the whole portfolio of projects.
I am concerned with some of the messages in your article.
“User Stories being translated to hours sets the duration expectation with developers” this statement goes against all of the successful Scrum implementations I have seen. It sounds as if you are locking the developers into delivering the User Story based on their Story Point estimate. In my experience this leads to developers taking less calculated risks, deliberately over inflating estimates, resenting ‘management’ for forcing deadlines onto them etc. In Scrum the Product Owner should be considering the ROI of each User Story. If the estimate from the team indicates that the User Story will be more costly then the Business Benefit that will be gained; the User Story is either split/changed to better realise the benefit or reprioritised or dropped entirely.
On the other hand I do recommend to Scrum teams in Planning Part 2 to total the estimated hours and use this as a guide to determine if they have over committed themselves for the sprint. This is a useful process that helps the team to go back to the Product Owner and re-negotiate the scope of the sprint if required. It is not there to put pressure on the team to deliver the User Story in a set timeframe.
The four questions you mentioned; such as “What types of work do we estimate poorly or take longer than expected?” are questions that the team(s) should be asking themselves in Retrospectives. The answers should then feedback into their Story Point estimates. If you as the Project Manager are often asking these questions then perhaps you are focusing too much on how the team(s) are working and not enough on how to help the teams.
Overall it sounds to me that you are fulfilling the role of a directive Project Manager, over a set of teams that are not empowered to guide themselves. It could have been your choice of words that has me concerned, however as your article stands it seems like your projects have some issues preventing them from realising the full benefits of agile projects. -
Hi Andrew, thanks for your reply. I must admit I also prefer you approach and use it when I can. (sometimes we do have to provide firm estimates up front so we are constrained)
In regards to your comments on User Stories being translated to hours, Mike Cottmeyer had an excellent blog post that commented much of the negative behaviour we have seen when we provide estimates in not the fault of the estimates but rather just good old bad project and people management after the estimates are provided. Being a developer in the past I know the position developers are in and I never even suggest a deadline. And I also know that once the estimate is given, things will change and the estimate will also change. I think one of the most important things is the team building trust within the team as well as with the customer. Everyone should know that the entire team has their back at all times.
A missed estimate is not a time for blame, it is a time for learning. As long as we get better, it is well worth the time and effort.
At the end, I think we probably are more similar than different in our styles. I would welcome to chance to work together in the future to show how my style is very collaborative. (I've never been called directive, but I'll get over it. :) )
Perhaps I could have chosen my words better. But I don't think I have Agile nailed either and have everything figured out. I'm learning as I go along and trying to get better. -
Generally, for some really new idea, you can't figure out if it's going to make you any money if you don't try it out and see what happens. For everything else, it's already been done, so just buy it from someone else.
The oft repeated "it's already been done" line needs to die. Just because something has been done doesn't mean it's going to work for a given organization. This is the reason SAP projects are notorious for nearly bankrupting companies. I know it's off topic but the reality is that if you go around buying things, you'll soon have a ton (we have hundreds) of things that don't work together and likely impose conflicting constraints.
The reality is that very little software is truly reusable across organizations. Only the most generic types of functionality (spreadsheets, word processing, etc.) are truly fully reusable across organization. For everything else, there are only opportunities to extract out portions of the software to make it reusable. -
Agree 100% that we need to stop using the overly simplistic "it's already been done" line. I was going to respond to this statement before, but I thought it was a bit off topic. Of course I may be somewhat biased as I work for a company that believes in Custom Software Development when it makes sense. (if there is truly a fit in the Marketplace, we do not recommend Custom Development)
I couldn't agree more that although there are Software packages out there that appear to be a match, rarely is it cost-effective to try and fit a product's functionality to a client's unique requirements and organization. At least the last client I worked for that implemented a package fully understood it was not going to be cheaper or more efficient, but they were doing for reasons of standardization. -
It seems to me that Terry is confusing Agile with Lean/Kanban workflow. Secondly, if one unwraps the techo-concerns cited, an optimal project can be defined as a traditional - fit-it-in-a-project-management spreadsheet approach to project management and a sub-optimal project is one that eliminates the waste of all that overhead much to the chagrin of all those project managers whose certifications taught them otherwise.
The degree of documentation necessary to ensure corporate memory will differ based on the work being done. That is a process issue. In Kanban, a sticky requesting documentation is added to the backlog column and it gets prioritized, no?
And the money issue is not the cost of product for say, six months but what can be delivered in that six months with the money allocated. Is high quality desired? A working, bare bones system? A framework? Seems to me this is the management part of the equation, not stampeding toward an end-date with an unrealistic expectation.
This, in a nutshell, is the modern-day equivalent of FUD. -
Thanks for your comments Frank. I don't think I am confusing Agile with Lean. I'm trying to propose that if both are used together they can result in even more value. I would never discourage the use of Agile, but possibly we can build on Agile and make it even better by using Agile Practices in conjunction with the principles of Lean.
My intent was not to present any FUD, but to present a different approach. One thing I do find troubling is that by suggesting changes/augmentation to Agile I frequently see FUD-slinging. Nowhere in my proposal did I propose an option that promotes a traditional fit-in-a-project-management spreadsheet approach with big design or documentation up front. I agree that those approaches have a lot of overhead and waste. My perspective is that Agile and Traditional are a continuum and is there somewhere in the middle (much closer to Agile than not) that can provide the maximum value for all involved.(and it probably changes for each and every project) But I have encountered the opinion before that if anyone is promoting estimates they suddenly are also promoting project death marches. Nothing could be further from the truth and these death marches are not the fault of the estimates, but rather the fault of bad management.
I agree that documentation will widely differ based upon the work. Sometimes stickies will be enough, but sometimes they probably won't be. But that is up for the team to decide. My preference is to let the team know that it is ok to create more documentation if they feel it is required.
I'm not sure what I proposed that gave the impression we were stampeding toward an end-date with an unrealistic expectation? FUD indeed. -
Terry, I'm not at all sure mixing and matching methodologies is that good an idea. I'm a big fan of Kanban and less so of agile and precisely because I think agile has also muddled the issues involved. But that's a different discussion.
I really do object to your "different approach" and there's nothing personal in it. It's just that I hear those same arguments over and over from profoundly ineffective project managers and leads who are plenty happy using Microsoft project to blow through one deadline after another after tediously predictable scorched earth marches that jettison every thing that gets in the way of the estimated deadline. Quality, features, and any semblance of coherent development practice routinely are strewn by the wayside for all of the very reasons you cite with all of the same rationalizations.
Now, one can argue from the point of view that any project done poorly will fail in one way or another. But the estimated deadline route has empirically failed over and over and over. So much so that I do not understand why advocating introducing it's worst transgressions to Kanban, agile, or plain chaos is sensible.
Forgive me if all of this sounds awful but I think many of us trying to break the death-grip of the certified PMP approach are near wits end with the stuff. -
Thanks for the reply Frank. I can certainly appreciate your concerns and what you have experienced. I as well detest MS Project and WBS with every fibre of my being. I certainly don't intend to support PMP or PMI heavyweight and prescriptive methodology.
Thanks for the feedback. -
Terry,
Reading all of your responses to the posted questions; gives me the sense that you are acting in an 'agile' way. Finding the right balance in these situations can be tricky, and I think the words in the article lead me slightly away from your intention.
Thanks for your response and good luck with all of your future projects. -
@Terry: I guess I have to disagree with your disagreement. I think that you can consider agile a failure for recommending to start the bad-ROI project, only if you can show a better way to forecast a project's success.
Moreover Agile doesn't recommend the start of the project without an estimate. You can feel free to make a non-agile estimate at the beginning. Just be prepared to readjust your position as soon as agile does provide a better ROI estimate.
Just my 0.02$
Assaf -
Thanks for the comment Assaf.
I couldn't agree more with your statement:
"Moreover Agile doesn't recommend the start of the project without an estimate. You can feel free to make a non-agile estimate at the beginning. Just be prepared to readjust your position as soon as agile does provide a better ROI estimate."
Very well put.
Terry -
Thanks Andrew. I think we are all just trying to find better ways. I believe there is never one best way. It always depends on the problem, project, client, and team.
My current project is implementing a Data Warehouse in an Agile way while being part of a large traditional project. Lots of fun and learning...
Thanks for the discussion. -
Do you mean "suboptimal" (as in not optimal) or "suboptimising" (optimising a part at the expense of the whole)? No need for a made-up definition.
Projects (with or without governance), a construct not required by Agile as a justification for programs?
Estimation and tracking as solutions to problems that might (depending on context) better be solved simply by delivering with a predicatable capability?
I could go on... -
Hi Mike, thanks for your reply. The intent of the discussion was to discuss we could be sub-optimizing with Agile and as a result create a sub-optimal process. So really both. :)
I agree that delivering with predictable capability is a better solution than estimating and tracking, but unfortunately for many of us this is not reality for our projects. So I've chosen to propose/discuss solutions to the problems many of us are struggling with.
Also asking clients to wait and see our velocity before we commit is a large amount of trust to request. Sometimes clients are not willing to grant that trust and I think we need to be able to work with them until they feel comfortable. Sometimes, that may mean estimates...
Thoughts? -
I have watched Agile groups with their CARDS and notes on White boards. After each sprint the board is cleared and cards find their way into the trash. There are several cheap technologies that can help save this important information. One is a Logitech io Personal Digital Pen which one can use to write all their story cards. You get a hand written card and also a copy stored in a PC or laptop. Once you have this info it is easy to store and update who took card and when and when card was complete. With such data you begin to have lessons learned and historical data that can be used from release to release and project to project.
Agile just needs to get more agile and think outside the box which was the whole point of being agile :) -
Thanks for your post Alex. I couldn't agree more. I actually have tried a few of the Agile project management tools out there and settled on TargetProcess. There are many other options, but I agree that by just using stickies we are potentially losing great information. I like how TargetProcess allows be to customize the Workflow and add new fields for any data I want to track... extremely flexible.
I especially like to update TargetProcess with the great discussions during Planning Poker sessions so we have reference to what we thought the design was when we estimated. The notes are nothing too detailed. Usually just between 4-8 bullets on design decisions. I find that when we are using stickies, these discussions are usually not captured at all. -
Given that an estimate is an 'educated' guess based on the knowledge people have at the time.
What relevance is an estimated amount of time to the time you actually spent doing something?
Does the same team (comprising the same people, who never learn and never forget) ever have 2 tasks that are absolutely identical? If they don't why waste time calculating whether any one particular task took more or less time than was estimated?
Changes in accuracy trends (averaged over all stories for each iteration) might tell you something is different with the team, if the team is achieving more or less than they estimated then their Velocity will reflect this.
Rob
20 comments
Watch Thread Reply