Show all posts
6 years ago

Relax, Agile Development IS Growing Up

I read Agile development grows UP article written by Mark Lines. It has quite a strange taste… Is it an attempt to advertise new methodology? I hope it is, otherwise Mark is completely missing the point and agile development trends.

I want to review the article. Just can’t resist, sorry.

Many of us don’t have the benefit of co-location, where the entire team works in close proximity (ideally in the same room), with the user representative present at all times to answer questions

Sure we all know that a co-located team is better. It is not a surprise that consultants advise to co-locate team members. If you need to win the race, it is better to drive BMW M3 than Ford Focus. There are so many discussions around distributed agile this year. There are so many ideas and experience reports on how to implement agile remotely. Agile works in remote teams.

Pair programming i.e. 2 programmers sharing 1 keyboard is an expenditure most management will not endorse

It’s a very strange argument. Many managers will not support continuous integration, iterative development and BDD. It does not mean that these practices are bad. Context is everything. In some companies and on some projects pair programming will increase productivity. While on other projects there will be no benefits or even degradation. How many agile coaches insist on pair programming and say “You are not agile without PP”? Not many. It is wrong to spread this argument to the whole agile community.

Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes.

C’mon! User stories can be VERY detailed. For example, you may use BDD-style user stories format and write many cases that will describe functionality in some format, that can be directly converted to unit tests! It is an incredible thing, to be honest.

Fixing architecture as you go (i.e. refactoring) without some initial architectural design is not appropriate for large-scale enterprise systems

Most people in agile community believe that it is required to spend some time on architecture. Again, it is so context dependent. If you create a simple application, one day may be enough to nail down all important decisions. If you create a complex system, it may take several months. Common sense is a critical factor here. There is always a danger to over-architect things and working software is the best proof of concept.

Also something called “emergent architecture” is being developed. I like the idea and maybe it is a right direction.

Most projects are not completely independent and cannot be built in isolation. Dependencies and integrations with other systems are required and require some co-ordination.

Agile adoption is spreading rapidly and indeed there are no common/standard approaches to solve this problem. But I believe it will be resolved during agile enterprise adoption (and we already stepping into this phase).

Organizations usually have some governance practices in place (such as PMOs, ISO, CMMI) that necessitate a level of bureaucracy and documentation

Does it all mean that PMO, ISO and CMMI are good and we should give up and follow the rules? Agile community tries to fight bureaucracy and I personally love that. Documented process means NOTHING for success of software development project. In 90% of cases it holds you in the spider’s net and blocks creativity. There is NO software development without creativity. Wake up, Mark.

We live with these standards, but we should fight them.

Deploying software to users every 1 or 2 weeks is usually not practical in most organizations. Just migrating software through development, test, system test, user acceptance, production environments is a major undertaking. Having many projects trying to do this in parallel on a weekly basis simply isn’t feasible.

This argument is so common… and “not practical in most organizations” is a truly masterpiece. Any statistic data? Did Mark try to deploy anything outside the enterprise-scale Java mastodon applications world? Many SaaS services do painless weekly updates. Some services do painless updates on a Daily basis! It is unbelievable, but I like that. Customers like that!

Mark promotes OpenUP methodology (based on Unified Process). Only advantages in the post, no disadvantages or context at all. Folks, I think it is a so long-awaited silver bullet! Finally it is there! Let’s bury Scrum. Let’s bury XP. Let’s burn Kanban and all the other processes that spark agile movement. God bless the OpenUP silver bullet. Amen.

Create a free account
Over 6 000 teams in 80+ countries
start their day with us. Welcome on board.
  • Michael Dubakov

    Exactly! I especially liked this quote: “Grady Booch (an IBM Fellow and thought leader on Architecture) told me that he recently received a call from Kent Beck (thought leader on XP) wishing to discuss architecture. Grady looked like the cat that swallowed the canary. Seems other methodologists are realizing that architecture and things like requirements are actually important!”

    Yeah, Kent Beck is a just graduated boy that heard nothing about architecture and called Mr. Booch to accept the fact that architecture still exists and he wants to learn how to use it in the code.

  • liammclennan

    Mark says, “Bickering over terminology and this idea that “mine is better than yours” is juvenile”, but then, “OpenUP is the freely available open-sourced version of the IBM Rational Unified Process… What makes OpenUP … different from other iterative agile methods is some common sense improvements”. He can't seem to make up his mind.

  • Mark_Lines

    Er, what.. what was that?? Thanks for waking me up Michael :) Seriously, thanks for your insightful response to my article. You make some good points. However, I do not mean to indicate that OpenUP is a silver bullet by any means. The title of the article is not supposed to suggest that Agile is not growing up, as it clearly IS as you suggest. The title was a play on words for Open”UP”. OpenUP is not the ”next best thing”, you could certainly use Scrum or XP as your base process. I should have spent a bit more time explaining what OpenUP is. It is a collection of Practices (such as Use Cases (or Stories if you prefer), iterative development, continuous integration and few others). They are part of the Eclipse Process Framework, an opensource effort to describe a set of practices common to all agile methods. The idea is that you scale your process appropriately by adding (or replacing) practices to supplement the core, generally accepted best practices of agile development.

    You don't have to call the result “OpenUP”, you can call it “Michael's method” or whatever. What makes OpenUP different is that it has an additional practice called “Risk Value Lifecycle” which stresses risk mitigation and baselining of architecture in the early iterations.

    Some projects DO need templates, checklists, steps, or other guidance when they do a practices such as TDD. Not all of us can do this based on tacit knowledge. So documenting these practices can help and this is what the collection of practices known as “OpenUP” does. Incidentally, there are Scrum, DSDM, and XP variants of these practices that have been bundled together as well. See for wiki links to these web-based guidance sites.

    Packing these practices into a cohesive set of practices that matches YOUR organization does NOT conflict with self organizing teams and kaizen. I like to say it is “more what you'd call guidelines than actual rules” (Barossa, Pirates of the Caribbean).

    I am not going to counter all of your points above, because you are absolutely right in that many organizations CAN refactor, do bi-weekly deployments, have too much bureaucracy. No argument! However, I CURRENTLY see more organizations that struggle with these things due to the bureaucracy and often disfunctional behavior in their orgs that they have little control over. They WANT to do these things but there are many barriers in their way.

    I work with management, as well as project teams. And we all know that there is usually a disconnect between the realities that project teams face (eg requirements being wrong if done up front) and what management expects (waterfall approach). Unfortunately, we sometimes HAVE to do things that contradict to agile principles to appease our stakeholders. This is a reality. My article suggests that IF you have to deal with a PMO, you can inject a Practice into the agile practices to meet the governance requirements. This doesn't mean it is recommended, but we can adapt to meet the realities we have to deal with.
    I think that the most important point lost in my article (perhaps I wasn't clear), is that OpenUP provides guidance to all members of the team (optional of course!). People like yourself that read boards like this and perhaps work in agile friendly environments perhaps don't need this guidance. However, I often work with teams that not what might be called “A players”. They have families, other priorities, and being an Agile guru and software development expert is not their number one priority. They many have never coded and be a “business analyst”. They don't know what a User Story is, and sometimes not even a Use Case. For people like this, self-organizing philosophies don't work (at least not initially until they learn). For instance, if they have only written 100 page Software Requirements Specifications (upfront) on previous projects, and you then throw them into an agile project and ask them to identify and estimate their own tasks, what do you think will happen? So some web based guidance/templates on Stories or UCs would be helpful, yes? Web-based guidance/templates via EPF methods such as OpenUP (or Scrum!+) can provide value.

    Your point on User Stories is an interesting one. My personal preference is “agile” Use Cases, since in my experience I have seen problems with Stories having poor functionality coverage. That is, usage scenarios can be missed if the stories are not structured around end to end scenarios. Perhaps there is a better way that I have not been using. I have some homework to do.

    I wrote the article in bit of a cheeky fashion to try and stir things up and generate some good discussion. I am glad that it has. I love Scrum, and DO think that Pair Programming makes sense in certain instances. However, what I am trying to convey at the heart of things is that a Project/Org should decide what makes sense, or what they frankly are capable of applying in certain circumstances. Additionally, supplementing Scrum with other practices can round out an end-to-end agile lifecycle nicely.

    BTW, as an aside and related to these org challenges, I really like Craig Larman's books. His book on Scaling Lean & Agile Development is an interesting read. While I love his work, I sometimes wonder how he can convince orgs to adopt some of his ideas. He suggests “avoid PMOs” and “avoid Performance Appraisals”. He makes powerful arguments to suggest that these are a waste of time and a disincentive to effective teams, but I can't imagine convincing an HR department that they shouldn't do performance appraisals. My point is that though there are many agile ideas that make perfect sense, some current practices in organizations are deeply rooted and will take time to change. I am trying to help organizations blend these great ideas within their current limitations.

    Maybe we will get there eventually, but it will take time.

  • Chuck van der Linden

    “Delivering a system without moderately detailed requirements (beyond User Stories) is not acceptable for testing, writing training materials, and production support purposes”.

    You know, I've been on many a team that started out with a fully detailed requirements.. and I can tell you first hand it wasn't of any use to Test, and I'm pretty sure not to any of the others mentioned. In fact I'd go so far as to say that it was detrimental and caused a lot of wasted work to be done. WHY? you ask… because the spec wasn't kept up to date. Stuff changed for one reason or another, and there was never time to update the spec.

    Of course nobody ever bothered to TELL me that (or the docs folks or…) oh no, I only found out when I had wasted a bunch of time testing stuff 'to the spec' filing bugs, only to get them back as 'by design' or a similar resolution, and at that point discovered 'oh yeah, we changed that..' I'll bet I can find many tech writer that's had the same sort of issues.

    We rapidly learned to ignore the specs because more often than not it lead you on a wild goose chase (and mind you, this happened to me many times on different projects, at different companies), and instead went and talked to people and had discussions about how things work etc.. and 'oh-my-gosh' that turns out to be the same thing you do with most agile stuff since the user story is supposed to be a basis for a conversation..

    and I'll second what you say about BDD style stories, those provide great real world examples for both testing (along sometimes with multiple sets of data for a given function) and also for people doing documentation. I can use BDD style stories with a tool like Cucumber to create an automated acceptance test that ends up being executable specification, since it's driven directly from the stories.

  • Scott

    Michael, a few thoughts:
    1. 45% of agile teams are colocated but that co-located teams have a 79% success rate compared to 73% for near located and 55% for far location. These figures are from various surveys, the results of which are available freely at .
    2. Mark didn't say that pair programming is bad, as you imply, and the stats do in fact show that few teams adopt pair programming and that many organizations try to prevent it. I think that's truly unfortunate, and push back against it wherever I can.
    3. You should have backed up your argument about architecture with statistics considering you complained that Mark didn't do so. Close to 90% of agile teams do some up front architecture envisioning. Also, agile approaches to architecture have been “emerging” for quite a few years now, it certainly isn't a new topic.
    4. Your discussion around regulatory compliance was questionable at best. One third of agile teams find themselves in a regulatory compliance situation (once again, the data is online and freely available). Yes, in many cases the compliancy strategy is overly bureaucratic, but in every case where I've seen this happen it's because the bureaucrats in the organization defined the strategy whereas the “pragmatic people” sat back and did nothing to help. If practitioners don't take responsibility and define the strategies which they're going to follow then they shouldn't complain about the results. If you allow the bureaucrats to define the strategy you'll likely end up with a bureaucratic strategy, no surprise there. BUT, if the practical people define the strategy you'll very likely end up with a practical strategy, and I've seen this occur several times in practice. Bottom line is that regulatory compliance is a reality for many agile teams. When we self organize we need to do so in such a way that it reflects the situation that we find ourselves in. Self organizing around the fun things that we like to do, but ignoring the things that we often don't like (such as conforming to regulations), isn't sufficient.

  • Michael Dubakov

    Thank you for some interesting numbers.

    >>If practitioners don't take responsibility and define the strategies which they're going to follow then they shouldn't complain about the results

    Wholeheartedly agree.

    >>When we self organize we need to do so in such a way that it reflects the situation that we find ourselves in.

    It is true, but not enough. If you have bad external condition (stupid regulatory rules) you have 2 strategies:
    1. Follow them, adopt team rules to be compliant and treat them as a “law of nature”
    2. Fight against them in every possible way.

    It depends on a personality what strategy to follow. I like the second. And even when I did not succeed in my previous career, I just left the company and start over in another one. It is just unacceptable to me to work under dumb rules and ruin my time. Life is short and there are many better places and ideas to strive for.

  • Michael Dubakov

    Sometimes compromises just bad.
    Scaling Lean & Agile Development is a good book indeed.

    >>but I can't imagine convincing an HR department that they shouldn't do performance appraisals.

    CEO should fire this moron from HR department who insist on performance reviews. All that stupidity holds progress and blocks innovations. While I understand roots of this sh*t, I believe we, at agile community, should do our best to break old and rotten rules.

    That was my point.

  • Valentin Tudor

    Should be a way for building an Agile CMMI :-)
    These two models are not completely exclusive. An effective CMMI approach should have embedded Agile practices.
    And reverse: some CMMI concerns could be introduced in an Agile process.

Request a demo
Our product specialists will show you the beauty and power of Targetprocess 3 and help you to customize it for your process and business requirements
Request a demo