Agile is Dead • Pragmatic Dave Thomas
Agile is Dead.
Agile values have been totally lost behind the implementation.
Dave Thomas (of The Pragmatic Programmer)
https://www.youtube.com/watch?v=a-BOSpxYJ9M
https://www.youtube.com/watch?v=a-BOSpxYJ9M
Agile is Dead.
Agile values have been totally lost behind the implementation.
Dave Thomas (of The Pragmatic Programmer)
https://www.youtube.com/watch?v=a-BOSpxYJ9M
https://www.youtube.com/watch?v=a-BOSpxYJ9M
long live agility: http://pragdave.me/blog/2014/03/04/time-to-kill-agile/
ReplyDeleteBrilliant quote from the post Jeroen Wiert Pluimers linked to:
ReplyDelete"forming an industry group around the four values always struck me as creating a trade union for people who breathe".
At work we seem to have naturally gravitated towards being agile. Customers rarely know exactly what they want. The other systems we communicate with usually have some quirks not specified in the file specs we get, like that system from a big-ass vendor which assumes XML files contain all the data on a single line (ie no newline characters). Or when the customer actually means "happens very rarely" when they say "will never happen".
So we write with this in mind. Things will change. We provide a starting point and iterate from there.
Asbjørn Heid i know that big-ass vendor :) or at least another one who behaves the same way.
ReplyDeleteDany Marmur Best thing is it would just silently discard those XMLs, so the only message we got was "the XML didn't arrive in our system". Standards? What's that? Gah!
ReplyDeleteI feel about Agile as I feel about political systems. Agile is the worst, except for all the other ones. (originally this quote was about Democracy). Questioning things and not accepting appeals to Industrial Status Quo is the fifth agile essential Value.
ReplyDeleteDelphi is dead for at least 10 years )
ReplyDeleteThat presentation is a lot of fluffy claims that does not connect factual dots. Agile, waterfall and other methods are all subsets of what is project management for software development. Instead of picking one subset, pick the whole package. Since I started doing that, based on ISO 13485 and IEC 62304, it has become very easy to manage software projects in all sizes.
ReplyDeleteMichael Thuma, I have been doing this for years. The international standards on developing safe software products for patients, REQUIRE that the software development is organized as a project, with clearly identifyable phases, and with a test phase that is subdivided into verification and validation. So your claim, that software development cannot be organized as a project, is clearly false. In fact, if you develop a first aid app for Android phones, the laws in EU and USA require you to organize it as a project.
ReplyDeleteI have completed many major software releases that are organized like that. The first work packages are usually project management, documentation and CAPA-initiated changes. Documentation could have been subdivided in several ways. Other work packages are usually centered on main groups of needs or main groups of technology development. The main criteria is, that each work package has a manager that has a well defined scope. Only that way can you scale easily way above 10 developers on one piece of software, where scrum really struggles to work.
The ISO/IEC standards, which are required by laws in EU and USA for medical software, require the V model, but allow agile changes to it. I think we had 21 versions of the design project plan in one of our major software releases.
If you want to have great efficiency, low testing costs and no critical bugs in a large software project, this is the way to go.
Iso 13485 requires documentation but is not so much a process as it is a random series of requirements for certification.
ReplyDeleteMichael Thuma: Maybe it becomes more clear if I explain what we do. We have a document management system with electronic signatures, but it is really easy and helpful. We also use design project plans. The main issues that our design project plans define are:
ReplyDelete1) How are conflicts between the teams/WPs handled. When many people work on the same source code, this is really important.
2) "Design Input" is handled really specific. This defines risk management, documentation, customer communication, management communication and helps programmers understand exactly how it must work. We have specialized tools to make this work scalable and easy, managing thousands of verifyable design inputs. Design Inputs regard design architecture, system architecture, functionality, performance, reliability. How are you going to test reliability? Maybe you are not. But then that should be a decision, and not sloppiness.
3) Documentation. When must which document be done in which state, so that we can review it and make sure that it finishes at the same time as the programming? We wouldn't want to have a time gap between end of programming and product release with documentation. Also, our customer must know how to service the system, and our sales dept must know how to sell it.
4) Communication plan and user needs. We must make the software for high usability and based on real user needs. Since this usually requires that we present our software to key user needs experts (aka doctors, BI specialists, IT experts etc.), and because this will affect what we do (agility), it is important for everybody to understand who these experts are, when we get which information etc. We may need to call in more experts if an area is not covered well enough. For instance, I am currently working on BI stuff, and arranged for 3 types of statistical software users to be profiled for making sure, that our software matches the market needs. The communication plan may also include stakeholders, that will have a significant interest in the software release. Different types of stakeholders need different communication plans.
5) Risk management... do we have programmers enough? What if the new technology takes twice the amount of hours? What if user needs are incorrectly described? What if our hardcore programmer gets drafted for military service? Or what if the key user needs experts do not want to spend time with us? It is irresponsible for a large software development project to disregard such questions.
6) Organization. If your software product is going to be maintained, you wpuld like to know later, who was involved, how.
7) Schedule. When are you going to need the performance test servers? When are you going to start the final tests on your product? When is the first beta release, when is the final release? How flexible is the schedule? How is it determined that a milestone is reached? This is all really easy once you understand it.
8) Interdependencies. Do we need the new json parser to work before we start doing json? Or can we start up with another json parser and then switch later? Do we need the archive functionality first or later?
The level of detail should never be more than what can be said for sure. If in doubt, keep it out of the design projct plan. But if your large team of developers must be kept in sync, you need to write things down so that they can look it up after presenting it. And they must all have an overview of the main things in the project in order to be able to provide input.
Michael Thuma: One of the biggest benefits of using project management methods is, that you get well defined milestones that are reached or not reached. When they are reached, it is time for cake :-) Design project management changes software development from being a number of frustrations to a number of celebrations :-)
ReplyDeleteThe blog post linked by Jeroen Wiert Pluimers nails it as far as Agile as a buzzword goes, however, I also think the blog makes a rather meaningless suggestion:
ReplyDelete"When faced with two or more alternatives that deliver roughly the same value, take the path that makes future change easier."
Determining what will make future change easier is a vast, complex, and not easy at all problem. Actually, I think this might be the root of all management and development Evil :)
Making things Easy is Not Easy, it's probably one of the hardest problems you can be faced with. Everyone has different definitions for easy, and that's just the beginning of the debates...
+Eric: I totally agree. This guy seems to work under chaotic circumstances, does not implement user needs and business needs well, and does not exploit the strengths of each team member. A good software development project must interface well with user needs, sales department, deployment technicians, business strategy, regulatory/political issues, work inside the scope/resources/schedule/quality frame or report/document that it breaks, and ensure that developers have fun doing their job.
ReplyDeleteGood quality has an important rule: If one member of the team says: "I don't have time for that now", or shows other signs of frustration, something is wrong with the way you organized it.
And good quality is the primary driver of productivity in software development.
I always felt that Agile was an exercise in short-sightedness.
ReplyDeleteMichael Thuma: I do not recognize your naming systems - but project management, it is. I am trained in PRINCE 2 project management and PMBOK (an ANSI standard on project management), and we run it as projects. It is correct, that the standards allow that you reduce the amount of project management, but usually that doesn't make sense, as project management is defined as managing the work of a team towards a specified goal or product design (e.g. software release).
ReplyDeletehttps://en.wikipedia.org/wiki/Project_management
Where I work, we are agile in the small-a agility sense, in that we value feedback loops, and self-criticism. We value improving our procedure, taking a small step forward, looking at how we did that, and revising our plan based on what we learned. We also have a requirement, enforced by the laws of the countries we operate in, to comply with the laws of the United States, and Canada, for software used in a heavily regulated industry. There are ISO and FIPS and IEC and other standards, and there are laws (CFR reg numbers are quoted in the US for instance). Our process has to be certified for certain ISO standards. The big question mark in my mind is, not only do our designs have any bearing on our implementations, do our "processes" (as stated in our certification) bear any relationship to our daily work. It's completely possible, in fact, it's almost certain, that in most places, these two things have almost no real connection, unless you keep fighting to keep the two really connected. We've opted to do the hard work and keep ourselves honest; To do what we said we would do. That means we are neither Agile or Scrum, or Waterfall. We're doing our own thing which meets our legal requirements, and which we find most beneficial to our customers, our team, and which drives final product quality up to levels acceptable for our highly regulated, and highly competitive industry. Everything that Dave Thomas says is directly speaking at me. I am not at liberty to be fully agile, and even if I were, I have grave doubts about Agile and Scrum's effectiveness, born of over a decade of watching it done badly, I even question if ANYONE is doing it well. I need more than to be told "I'm doing it well". I would need to work with someone who does it well, and find out what they mean by that. Did they modify Agile? Then, I might believe them. Or do they believe in something like Stock Agile? If it's the latter, then I'll just call bullshit right now.
ReplyDeleteI didn't mean to say "we are Agile". I meant to say 'we are not Agile". I also said we value agility, and when I say 'we are agile in the "small-a" sense' that is all I mean. Doesn't that make sense? Do you really think that there is any meaning to these things "you are agile" or "you are not agile"? These things are flavor words, not facts. You can be flexible, and you can value agility, even in a process that meets legal requirements. You are not permitted to skip the step where you define a feature before you implement it. That is where we vary most from the Agile-crapfest "just code" and the "just write the test" mentality, which is what I most hate about Agile, and TDD respectively.
ReplyDeleteWarren Postma: We implemented the ISO/IEC standards throughout everything. We do not review anything without a written design review record. We do not have a bug-list, but only a CAPA list. I can trace every single line of code we make, back to who endorsed this, based on which info. In addition to the ISO/IEC standards, we also implemented several best-practice methods, in order to ensure, that we don't keep any information outside our QMS, and to ensure, that we only create documents that we will use later. In average, I probably signed 2-4 PDF documents per day, during the last 6 months.
ReplyDeleteMichael Thuma: In ISO 13485, design input (aka main requirements) must be approved, which normally means that the software development department (aka design dept) is the main contributor of requirements, and that only the user needs come from business, customers and other stakeholders. So, you don't really have to "sell requirements to the developer", it is the developer team (aka design engineer team) that comes up with the requirements.
ReplyDeleteWarren Postma: On my currrent project, which has a scope and schedule defined outside my jurisdiction, the scope allowed us a lot of freedom, and during the project, we scrapped our basic technology, developed new technology in order to improve programming speed, caught up with the schedule, and replaced almost half of the originally intended feature list with another feature list as we discovered, through frequent interaction with use specialists, that the original ideas would not be the best for solving the actual user needs. This took 8 versions of our design project plan, and shows a lot of agility and control. The result is a world-first product that beats the pants off other solutions, cutting down 12-month customer projects to less than a day. I don't believe that it would have been doable in a scrum setting, it is only doable because we use the project management approach, and all do things according to the ISO/IEC standards.
ReplyDeleteLars Dybdahl Sounds good to me. I like the word Pragmatic a lot more than I like the word Agile, because it is about results. If your results are good (or Great) then your process is working for you. It's the cargo-culters who have destroyed whatever was originally good in Agile.
ReplyDeleteMichael Thuma: I have many types of projects. The latest had a clear schedule, the previous had an ongoing evaluation of scope/schedule but a fixed resources per time. It doesn't change much in what we do, as changes just trigger a new version of the plan.
ReplyDeleteWarren Postma: Agile programming is simple. If you are 100% scrum or 100% something else, then you are not 100% "agile". So, ours is not 100% "agile", but we are definitely agile. The time from idea for a new direction, until 20+ employees work towards that new direction, is less than a day.
ReplyDeleteInteresting post, thanks. ISO 13485 tries to "unlock" organisations that become too static about their plans ny requiring that they are updated - i.e. if you do not make at least 2 versions, you are not conform. Also, IEC 62304 requires, that you divide up your software and treat different parts differently, from a planning perspective. I.e. if you use same planning for all parts, you are not conform with the standard. This is actually agility... you are forced to look at the physical world, to assess your software's impact on real life, and adjust your plans differently on each software part.
ReplyDeleteWe do not have full documentation on old pre-ISO reports, but the latest reports have great documentation in-house. It is really needed, because our reports are extremely complex. The reports can create a great overview from complex data using complex operations, so that the user sees that a complex reality looks simple. For instance, we have a report about Ventilator Associated Pneumonia, and then it must be defined, how much time may pass in order for something to count, what about double incidents etc. Readers do normally not care, but in some rare cases they do. And then our support dept must be able to answer precisely, without having to read the source code.