title: Agile!
subtitle: The Good, the Hype and the Ugly
author: Bertrand Meyer
publisher: Springer International Publishing Switzerland
year: 2014
city: Zurich, SwitzerlandThese are my raw notes from reading the book, unrefined and incomplete. Read at your own risk. The end goal would be to combine these with other notes on Agile when I have time đ
Index
This text is meant to aid readers to benefit from the good ideas in agile methods and avoid the bad ones. Examples of Agile Methods are:
The book aims to provide a description of essential agile ideas and techniques that arenât tied to a particular agile method. It Also aims to provide an assessment, taking a non-biased look at agile methods and determine what helps and what hurts. You do not have to agree with the conclusion.
Three challenges from existing information are: partisan, intimidation, and extremism.
Extreme Programming dates as far back as the 1990s, but the âAgile Manifestoâ was created/appeared in 2001. Rather than a single development method, Agile encapsulates a set of ideas that are then developed into several methods, like Extreme Programming (XP), Scrum, Lean Software, and Crystal. Many people and teams use some ideas from a method without embracing it completely.
We will aim to review the following core characteristics:
Five general Agile tenets:
For tenet 1, Agile methods redefine and limit managerâs job by transfering many duties to the team as a whole. This includes selecting tasks to be performed and assigning them to developers. Agile methods are, in part, the rehabilitation of code.
This redefinition of roles also affects customers, who donât just receive products but activily participate in their development.
The 2nd tenet is regarding software engineering techniques that involve extensive planning at the beginning of a project, and basically to not do those. Principal examples are:
By consequence, Agile is âiterative, time-boxed development.â (Tenet 3) Agile alternative to requirements document is a prioritized list of functions for a team to select from during an iteration, also called a âsprintâ in Scrum. Typically select the highest Return on Investment task.
Tenet 4 is about implementing functionality with highest ROI. A team shouldnât waste time on implementing features that hardly anyone will use. Lean Software treats unused functionality as âwasteâ, and promotes âwaste minimizationâ as a core concern. âKanbanâ seeks to minimize âwork in progressâ.
Negotiation occurs when choosing functionality for each iteration. Itâs not realistic to commit to both functionality and delivery time. An missed functionality during one iteration is reassigned to a subsequent phase or dropped if deemed insufficient ROI.
The final tenent essentially means continuous testing. Emphasis on role of a projectâs regression test suite, which is the set of tests taht must pass.
We will also consider the following as core Agile principles:
These principles follow the five general values previously discucced. They are not the 12 principles from the Agile Manifesto as those are less appropriate for analysis.
Covers first 5 principles. âSelf-organizeâ refers to teams deciding their own tasks. âSustainabilityâ requires programmers work reasonable hours, preserving evenings and week-ends.
Accepting change refers to full requirements cannot be determined at the beginning.
Agile development implies an iterative development process, consisting of successive iterations. Each is fairly short, and produces a working release of the software. Customer representatives can then try out software and provide reactions to fuel the next iteration.
Author in this book is keen on test-driven development.
Also, âscenarioâ is not a common Agile term, but covers variants such as user cases and user stories. A use case is a complete interaction. A user story is an application of a smaller unit of functionality. Scenarios are obtained from customers.
Key Agile Roles:
Principal/Key Agile Practices:
Scrum specifically requires a daily meeting at the beginning of each day known as the âdaily Scrumâ. The meeting is kept short by answering 3 questions:
Itâs meant to help teams remain cohesive, everyone knows what is happening, and easy to spot problems early.
XP implements the planning game, and Scrum implements planning poker, which are both estimation techniques which asks participants to come with initial estimates independently. Then, reach a consensus together.
Letâs talk about paired programming. It is promoted by XP. Code is systematically developed by 2 people sharing a workstation, one does the typing and explaining their thoughts, the other making comments and suggestions. A pilot-and-navigator if you will. XP presents paired programming as the only mode of development.
XP also popularized practice of âThe simplest solution that can possibly work.â It shuns any work that is intended to make the solution more extendible or reusable, which is usually recommended by conventional software engineering priciples. The idea is that such work is illusory anyway, because the software may never need reuse.
Agile artifacts are supporting tools, like user stories and story cards:
difference between use case, and user story is âgranularityâ. A use case cover a full run through the system. A user story is a smaller unit of functionality expected by users. Thatâs where we write like: âAs a customer, I want to see a list ofâŚ, So that I canâŚâ
A burndown chart is like a chart of tasks over time, and it should approach 0. Maintaining a burndown chart is a way to make a team aware of progress and alert when not discharging tasks fast enough.
The story board setup has following: to do, in progress, under test, done. Weird since itâs meant to be test driven development.
And office is suggested to be and open room to promote interactions instead of closed offices. However, thereâs a Harvard study that suggest exactly the opposite as people prefer their privacy.
See www.samuel-johnson.com/apocryph.html, maybe w/out the hyphen. Agile approach to requirements based on user stories. They are a valuable tool for validating requirements, but inadequate for defining requirements because they only document examples of system execution. Actual requirements must go beyond the user story and identify more general ufnctions of the system, or the system will only do a few things and little else.
Author discusses paired programming again, suggesting it âcan be an effective technique if applied with reason.â
Thereâs also a bit of a clash between Agile suggesting develop only minimal software, produce only whatâs requested, develop only code and tests, and the software engineering practices of generalizing code for ease of extension and reuse. But in Lean terminology, those results are wasteful, since not delivered to customer. Basically, think of ROI.
Also, Agile may reject upfront requirements when preventing no big upfront steps, but upfront requirements arenât useless. Just know they could be subject to change. The author goes as far to say, âThe Agile advise here is irresponsible and serious software projects should ignore it.â Itâs usually sound practice to start collecting requirements at the beginning, but treat them as a living product.
With that said, iterative development is something Agile promotes and has basically always been.
What Agile does bring to the table is team empowerment. One of the simple but great ideas is from Scrum, with daily meetings. it reinforces programmer interaction. Another good idea could be freezing requirements during iterations. Itâs a must for software to be flexible and change, but change is not always welcome in Agile. This can bring stability to the software process.
And testing is always a must.
Auther references âimportantâ Agile book, Succeeding with Agile by Cohn. As they state, writing down requirements doesnât mean a user gets what they want. At best, they get what is written, which can have different interpretations or even be misleading.
However, now the author tears into that statement, suggesting that Cohn is dangerously providing proof by anecdote. This merely proves that a generalization does not hold. It may back an argument, but shouldnât stand on its own.
On the other hand, having documentation/requirements written down is good because of moments when âI thought you knewâ causes 2 weeks of debugging. Like how caching works at my current job.
When writing beats speaking. Well, you write software, so makes sense to write requirements. Especially due to turnover and such. Auther argues:
Personally, I think you can also come up with a better and more detailed response when given time to write it down, instead of trying to explain something on the spot.
Words of caution:
Verbal communication is a complement to written documents, not a replacement.
Many Agile authors advocate their approaches using unsound methodology. Letâs cover some of the unsound methods one will come across when reading Agile documents:
Agile books largely make their point through anecdotes, looking at edge cases and creating new problems with their solutions. Anecdotes are good for supporting an argument, but not for making generalizations. If another person has an opposite anecdote from experience, they can easily reject the generalization.
Also be aware that, when talking about intimidation, a logical fallacy may occur that event B implies event A because event A implies event B. Obviously not always the case. Sometime, event happen to be side effects of multiple different events.
If you are not an enthusiastic promoter of Agile, you are a dinosaur.
Regarding the cover-your-behind caution, the author pulls an example from Lean programming, where after seven chapters of radical ideas, Mary and Tom Poppendieck leave you with a list of cautions. Our author argues it doesnât help the reader but the author of the Agile method cover themselves.
In these cases, I understand where our author is coming from. If instructions are meant to be interpreted instead of followed literally, then the initial wording should reflect. Itâd be terrible to read the first 6 chapters of a book and begin implementing radical ideas, just to get to the last chapter and find out you shouldnât have.
Finally, it is hard to perform large-scale studies of the effects of software development techniques. Many companies donât want to put in the effort or share their results. Also, IBM actaully did a study assessing Agile methods, but it was conducted in collaboration with the Scrum Alliance. Coincidently, it had good things to say about Scrum.
Look up the âHawthorne Effectâ.
p. 31 (48 of 181)
Every hero needs a villain. Who are villains of Agile?
The âanythingâ includes requirements and design. This chapter will briefly cover the âplanned-basedâ approaches resented by Agile. A detailed kdeep-dive would be its own book.
The Waterfall is a specific lifecycle model whose main role is pedagogical. Itâs more of a textbook example of how not to organize a software porject.
Predictive means more like organizing a greater or lesser part of design and production process in advance, based on techniques of science and management. It sounds more general, possibly many more specific approaches can be catagorized as predictive.
Requirements Analysis is a task of defining what a problem really is and what kind of solution will satisfy the stakeholders. Probably most important aspect of successful software development. Software engineering is about building systems right; requirements are about building the right system.
An important part of requirements analysis is requirements elicitation, which is the gathering of user needs. Techniques for this include:
Resutls typically includes a requirements document, summarizing objectives of system. Other outcomes include a system test plan and a development plan.
All variants of Agile reject the idea of upfront requirements. Requirement documents are a form of âwasteâ for 2 reasons:
Food for thought, the waste criticism, in principle, is limited to unused requirements, such as not analyzed and designed. Writing requirements is meant to provide a sound basis, early in the project, to discuss the systemâs future functions and decide which functions to drop.
The Agile approach is to design and get feedback. Eventually, a customer may drop an unnecessary feature. As an agrument, was that not wasteful, more wasteful that writing down the idea? Itâs cheaper to kill a feature in requirements than after wasting implementation resources.
Also consider developer moral, as discarding a feature may deflate it.
However, you may not know how useful (or useless) something is until you build it.
The problem is dogmatism, and condemning either in an absolute manner can harm a project.
Aside: Then perhaps there is a mid-ground labeling, priority, decision making system? For me, without a plan to review, things become short sighted and confusing.
Basically, huge and thorough requirements documents, describing every detail in advance, is a waste.
Additionally, even following a strict definition of âwasteâ may not exclude requirements documents because they can serve as a basis for writing system documentation. So, perhaps a better way of looking at things isnât right or wrong, but how can we get the most out of what we got.
Agile is correct that it is hopeless to freeze requirements, especially at the beginning of a project. However, the requirements document is a resulting artefact of software development, along with code and regression tests. In a sense, requirements are software, and like other components of software, should be treated as an asset. And like all software assets, they are subject to change.
An important note is that writing requirements does not imply freezing requirements. People arguing about a phase of development needed to result in a static document must not plan to update and maintain their software.
Another consideration when comparing Agile to other processes is a distinction between domain and machine requirements.
For a banking application, rules regarding actual accounting are domain properties. But specifications of how to process payments and other operations are machine properties. Also, consider when the natural laws of physics are concerned, like speed of connection over a wire.
These requirements are often combined but should be kept separate because of their difference in nature. The project can define the machine, but probably has no influence on the domain. Some authors argue that design and implementation are acutally the same thing.
Regardless of how you look at it, abiding by domain properties are hard requirements.
Agile does identify a real issue, the risk of spending too much time too early on design or implementation decisions. Sometimes, it is better to defer until more information becomes availabe.
âThe speed of light is not an implementation decision.â
If requirements analysis handles identifying the problem, designing is part of the solution. We will call the modular structure of the design the architecture. Examples of design decisions:
There isnât much meaningful difference between âDesignâ and âArchitectureâ. We will consider the former to be the process and the latter to be the result.
Many smart people believe thereâs no clear divide between design and implementation (production). An interesting argument is that even the production phase will include decisions that influence performance and are therefore part of the design phase. Implementation is a continuation of design for software engineering.
Another interesting characteristic of software is that it may make more sense to perform the design after writing the code. Think of a mathematical proof, neatly laid out where each proposition follows the previous and implies the next. However, if you ask the mathematician how it was derived, their story may appear disorderly and chaotic.
There is no single articulated Agile approach to design. However, there are three key ideas:
The first observation is that Agile de-emphasises extendibility and reusability of code, which is a common practice. Refactoring is also a sound engineering technique, but is not a replacement for good upfront design. Refactored junk is still junk.
What can go wrong with a big design?
Why is at least a little upfront system-level design good?
The idea is to avoid doing too much at the start since all necessary information is not available. However, itâs not a reason to ban all upfront design.
P. 41 (58 of 181)
Lifecycle models try to identify the steps a software project goes through, such as:
Best known models are waterfall and spiral. You donât need photos.
Lifecycle modesl play 2 distinct roles:
âLifecycle concepts considered harmfulâ by McCraken and Jackson, an article from 1982 discussing prescriptive sense of Lifecycle models.
We have 3 arguments for considering a waterfall-like model:
However, actual use of waterfall is discredited today, and rightly so.
p. 42
Rational Unified Process promotes a waterfall-style with an iterative approach, and combines with a number of recommended software engineering practices. Most important contribution is 6 recommended practices:
Itâs also recommended each project involves 4 phases:
First 3 are like requirements, design, and implementation. And Transisition is another term for deployment. RUP, however, is not popular in Agile circles because it can have the Big and Bad Upfront Costs. Itâs also too sequential.
p. 43 (60)
6 recommended practices of RUP:
All but âmodel software visuallyâ correspond to widely accepted practices of SE. Lifecycle models involve 4 phases:
In parenthesis are similar and more common concepts. Note that deployment was absent from traditional models because software issues were simpler in 1970.
RUP is not popular in Agile Circles because it has Big (Bad) Upfront Methods. It is also too sequential. However, requirements are managed with user stories, which are defined iteratively, and supports continuous verification.
Started in 1980 with ISO 9000 set of standards from International Standards Organization and Capability Maturity Model (CMM) aimed at software specifically. We will look at CMMI, the âIâ is for âIntegrationâ.
p. 44 (61) 3 Notions:
A process area is a clearly identified aspect of the software process (eg configuration management, project planning, risk managment). CMMI defines some generic goals and practices applicable across process areas.
Apparently, you move through CMMI levels, but qualify through an assessment process conducted by an approved assessors. Sounds like a scam.
There are 5 levels, ranging from negative and unstable to optimized. Back in the 1980s, the US Department of Defense was the largest consumer of software products, and they liked specifying a standard.
CMMI, based on concept and cost, was meant for large organizations. Personal Software Process (PSP) is largely outdated but the practices are kind of relevant even still and worth noting I guess. Things like keeping logs, tracking time, recording bugs, etcâŚ
No fundamental contridiction exists between Agile and CMMI. However, they are perceived as incompatible.
On the contrary, if you need to implement CMMI through Agile methods, you can find reports devoted to CMMI level 5 using Scrum.
p. 47 (64)
It appears some Agile frameworks try to mimic CMMI with its 5 levels. However, a closer counterpart is Shu-Ha-Ri (Shuhari), a 3-step gradation:
2 concepts:
Principles should be precriptive, not descriptive. That is, it directs an action or actions.
p. 50 (66)
Agile Manifesto lists 12 principles. Not writing them verbatum now, look in book.
Some of these are actually practices and platitudes. Think of a platitude like an obvious statement, like working with motivated individuals. Additionally, some are not prescriptions but asertions, like aiming for simplicity. This is OK unless the assertion is wrong.
Author argues that these rules are a bit redundant, mentioning frequent delivery several times, and incomplete, not mentioning testing explicitly.
p. 51
We will look at the list from the âOverviewâ chapter. They are in the book, and quite similar but more thorough as well. Looks like we will cover them in depth.
Think project management, scheduling and team organization.
Thereâs a lot of information, so Iâll try to be quite concise with bullet points instead of using several sub headings.
Organizational:
Agilist folks want to have their cake and eat it too.
Technical:
P. 79
Agile Development methods redefine roles for managers, customers and the development team.
Managers actually have a list of things they shouldnât do, such as:
Sounds like the Manager is restricted from micro-managing. These tasks are spread to different areas. What is left for a manager to do?
Scrum specifically goes further by not including a manager role and only having:
And the management responsibilities are divided among these roles.
Product ownerâs main responsibility is to define and maintain the product backlog (ie list of features). This is product level functionality, and not individual tasks to implement functionalty. They are also crucial to sprint:
A Scrum product owner also decides on functionality. However, they donât enforce rules (Scrum Master), nor assign individual development tasks to implement selected user story (to the team).
The Team takes over the critical role of deciding what tasks to implement.
Agile teams are characterized by self-organization and intense collaboration. Agile literature defends that self-organizing does not mean hands off completely. Managers are still important, but just not required for everyday decisions.
p. 81
Interesting concept -> Teams that can deliver useful features independently of other teams. This implies that teams should be formed along the lines of features and services.
Rejected alternative is team divisions based on areas of competence (eg hardware vs. software). Instead, it is recommended to divide along âuser-visible subsystemsâ.
In the Agile world, and Scrum in particular, there are 2 kinds of participants for any project:
The joke involves a chicken and a pig. The chicken asks the pig if he wants to open a restaurant together. The pig says maybe, and asks what it would be called. The chicken says âHow about âHam-n-Eggsâ?â, to which the pig replies âNo thanks. Iâd be committed, but youâd only be involved.â
In the context of Scrum, chickens have input on how the product is developed, but pigs decide how itâs going to be done and the rate it is accomplished.
Note: The website also has a tutorials section for creating many diagrams.
Agile Academy Chickens refer to people involved in a project but not responsible for a specific outcome. A Pig is someone who is directly responsible for the deliverables.
Scrum Guide mentions that the pigs and chickens have been removed from the Scrum Guide. The guides still makes a distinction between members of the Scrum team and other only a part of the process, but doesnât use metaphors as it was thought to derogatory and created a negative persona. People described as chickens often felt powerless and as such, lacked engagement.
Side note, the Agile Academcy - Scrum Guide is an article probably worth reading to understand Scrum more effectively.
Our author offers other variations such as members and observers.
We have seen that Agile methods put customer(s) at the center. A consequence is to emphasize the role of the customer throughout the project. In some cases, consider them as a member of the project.
Early models limited customer involvement to the beginning and end of the software development life cycle. Some project environments also discouraged customer contact or prohibitted interaction between developers and customers.
Agile methods require customer interaction. However, different Agile approaches encourage different levels of customer involvement. There is apparently anecdotal evidence that it is difficult to integrate even a well-meaning customer representative into the development team as exclaimed by the XP approach, and the Scrum approach having the Product owner represent the users is the superior method.
I believe one of the papers I read also mentioned how ONE representative from the company / customer can guide a biased product tailored only for them and is useless to other stakeholders, or packed with useless features and lacking more esential ones.
Teams require enforcement so they donât stray from recommended principles. Although the project manager can play this role too, it is recommended to assign it to a different individual.
XP insists the role of a Coach is to advice and not prescribe. âCoachâ suggests a training role. Scrum Masters, addtiionally, take on a managment role. However, I believe both are evidently responsible for ensuring their team lives by the values of their Agile approach.
Additionally, another important role is to remove impediments identified by team members in daily meetings.
You can become a certified Scrum Master. It is debatable that a Scrum Master will only do that job, and not be a developer. A Scrum Master that also gets their hands dirty can lose objectivity, and form a bias.
However, the author kind of disagrees. A Consultant can take credit if the project succeeds and blame the team if it fails. So there is a fear that the Scrum Master could do this. Also, for the Scrum Master, their work isnât tangable, but dependent on the teamâs performance.
In India, they use the term of Technical Scrum Master for a SM who is also a developer.
p. 86
Scrum forcefully insists on only 3 roles: Product Owner, Scurm Master, and the Development Team. What is the good and the bad?
Separating managerial role from the Product Owner can be helpful. Some companies find it hard to draw a line between the business and the software because the business is software (ie Google, Facebook). Merging Product Owner and Project Manager risks the person being too close to the problem. The Manager should focus on business needs, but runs the risk of getting too involved in the project.
However, with limited resources, other roles may consider merging:
p. 89
We looked at different roles for a software development project. Now, we will look at some practices.
What is a practice in software development? A practice is an activity or way of working with repeated application. It must occur regularly / enforced systematically, else itâs just a once-off thing.
Scrum calls practices âceremoniesâ.
All Agile methods develop iteratively. Scrum uses the term âsprintâ as the name of an iteration. Purpose of sprint is to advance the project by a significant increment with tasks from the sprint backlog.
Each task on the list is defined as the implementation of a âuser storyâ.
Sprint typically 2-4 weeks. Important, especially to Scrum, during the sprint, the task list does not grow.
Supposed to be no exceptions. If there are really pressing needs, they should be parked until the end of the current sprint and examined for possible inclusion in the next sprint.
If there are issues, you can make the extreme decision of terminating the sprint early. This decision is privilege of the product owner, considered drastic.
My team currently implements a Sprint Refinement session mid-way through the sprint giving an opportunity to make adjustments if necessary.
p. 90
The closed-window rule is that the window for changes is closed whenever a sprint is in progress. The author made this name. One of the biggest obstacles to successful software development can be disruptive feature creep. Customers and managers may have ideas that they push to the team that can interupt priorities, which can politically be difficult to refuse without a clear policy.
Closed-window rule is meant to fight the feature creep indirectly by channeling it into sprint planning exercises instead of just putting features on someoneâs desk.
Author agrees with strict prescription of rigid sprint. They suggest calendar month as âsimplicity breeds focusâ.
The closed-window rule can be seen to contridict the Agile Manifestoâs principle A2, âWelcome changing requirements, even late in developmentâ. However, it provides a framework for handling changes by just not welcoming changes at all times.
Iâd say that changes / suggestions are always welcome. But the customer must recognized that the change hits the backlog until the next sprint.
Stand-up meetings, or the daily scrum, are short meetings where each team member answers 3 questions:
Agile believes that direct contact is critical to project success. They are short to keep it lean, not being a long waste-inducing meeting / practice.
The stand-up meeting is not intended to solve problems or engage in deep technical discussions.
Answering first 2 questions ensures members make realistic commitments and fulfill them. The questions are meant for the boss to see who is behind schedule, but an opportunity for team members to make commitments to each other.
For Scrum, removing impediments is one of the key responsibilities of the Scrum Master.
Two threats to stand-ups are:
This is where a Project Manager, or Scrum Master, can:
Auther throws a little shade at distributed teams, which I donât believe is relevant anymore.
For time-zone based issues, sometimes it is more convenient to hold two longer meetings per week. The author did research and found an initial one-hour meeting at the beginning for developer and deadline-based topics, checking progress, small technical discussions. One hour time limit is strictly enforced. Longer and deeper issues are moved to another small meet-up or the second weekly meeting, which is agenda-based. The list of issues/topics are collected in advance by the meeting secretary (rotating role). Decisions are recorded as âaction itemsâ. Variations are welcome.
The âPlanning Gameâ comes from Extreme Programming, and is called âPlanning Pokerâ in Scrum. It addresses one of the toughest challenges of software management and development, estimating the cost of a system to be developed (or part of that system). Also remember that Agile typically doesnât like the idea of big upfront tasks.
Unit of estimation has traditionally been unit of work:
The âgameâ idea comes from game theory. The business and development actors try to maximize different criteria and seek an optimal compromise. The game concludes when the sides agree to select highest-priority tasks with an appropriate total cost and time allocation.
The Scrum side, how to estimate the cost of user stories in advance. Two main ideas:
The panel of estimators is the development team and product owner, and other customer representatives as appropriate. Goal is to reach a consensus, but avoid reaching it through intimidation. Process of estimating cost of functionality elements has the following steps:
Some love the Planning Poker. Auther says you can see pressure from power of majority. Even as an expert, it may be hard to argue your point for long without appearing arrogant.
p. 96
All Agile methods recommend involving customers. XP considers an âactive customerâ or an embedded customer.
Closed offices and cubicles are anathema to Agile development. This is because of core role of communication. For some reason, it means working in open spaces.
I hate and disagree with the words written on page 96.
Recommended Agile layout is:
Some people apparently like this, others purchase noise-reduction headphones.
The Author states that open spaces are not a solution for all people at all times.
Part of respect due to programmers (advocated forcefully in Crystal method) is to accept that people are different and not force a single scheme on them.
Process miniature -> get familiar with a proposed software process by applying it to some non-software tasks over a short period, a day at most.
p. 98
Agile practices have many meetings. At start of an iteration, a planning meeting should take place. 3 outcomes for entire team should be:
Note: we do not assign tasks, that is done at last possible moment. Additionally, testing should be done continuously during implementation of user stories.
p. 99
Mirrors the planning meeting but to assess what happened.
Additionally, good time to reflect not just on what was done, but how it got done. Scrum separates meetings, the latter is the Retrospective.
What went well and what didnât go well during the sprint? What can be improved for the next one? Looking to optimize the next sprint and nearly create a feedback loop.
Inward looking at team and coach / Scrum Master, but can also include product owner.
Basic Agile techniques are intented for teams up to 10 people. Scrum of Scrums is defined as a metting consisting of one member from each team in a multi-team project. These meeting can happen 2-3 times a week.
Challenge is coordination:
This is probably more for software teams, not software and other teams. Meetings help address first problem. Dependencies should be avoided if possible.
In many projects every software module or subsystem is under the responsibility of a specific person. Itâs not owned like intellectual property, that belongs to the company, but in a sense of technical authority.
Thereâs a benefit that someone in charge feels responsible for software consistency and integrity. It might fend off general degradation due to inconsiderate extensions (creeping featurism).
The risk is creating knowledge silos. Additionally, there would be barriers to change.
XP promotes collective code ownership. It also has a dangerous statement that âany two people sitting together and agreeing on it [the change] can change any line of code in the system.â
Crystal says, âchange it, but let me know.â
Interesting thought -> If people arenât afraid to add code, but are afraid to delete it⌠code bloat.
An extreme suggestion of Agile is to assign the next task to the next available developer. Only works if everyone can work on everything, interchangably. This is Agile assumption of cross-functional teams, developers are generalists and not specialists.
You can imagine pros and cons (p. 102).
p. 103
In this text, the author discusses the impact of agile principles on software development techniques. They mention that while the previous chapter focused on management-oriented practices, this chapter focuses on the corresponding development practices. The author notes that there is a strong presence of Scrum in the previous chapter, but many of the practices discussed in this chapter come from Extreme Programming (XP). This distribution of roles is attributed to Scrum being a generic management methodology, while XP was specifically designed by programmers for programmers.
The author acknowledges that the number of techniques covered in this chapter is not extensive, as many of the significant contributions of agility are related to project management rather than software-specific ideas. However, the author emphasizes the importance of one particular technique discussed in this chapter: test-first development. They state that test-first development has already had a profound effect on the software industry.
Integrating a software project means taking the components of the software as written so far, compiling them together and running the tests (the regression suite).
Big Bang approach = traditional process where developers develop their parts and try to integrate everything at the end in a Big Bang. Note this method is not great as assumptions diverge quickly and components become incompatible.
Better tools, like Git, make collaboration easier. Additionally, integrations on shorter cycles keep the team in sync.
Microsoft used to do the daily build back in the 80s. XP recommends a continuous integration. That is integrating and testing changes after a couple hours. However, running and building tests takes time. I think the creator of XP, Beck, dismisses the issues by saying that the wait time provides an opportunity for the programmer pair to discuss long-term issues. Yes, in an ideal world, all humans do is workâŚ
Poppendieckâs advice is to integrate frequently enough to do it rapidly at any time without finding defects. Itâs not an exact duration.
Pair programming is cornerstone of XP. It is only occasionally practiced today. Enthusiasts come up with new variants such as mob programming. The idea has retreated from the limelight as other Agile practices are considered more important.
Pair Programming (devopedia.org) can yield better software faster and at lower costs if done right.
In a sprint text, and article âThe Effect of Pair Programming on Code Maintainabilityâ by M.Nawahdah and M. Jaradat, they sat folks down to write small programs and found pairs wrote 50% less errors, 30% less code, and 25% better code. Again, the sum of the inputs is greater than the output.
Please read âAre Two Heads Better than One For Software Development? The Productivity Paradox of Pair Programmingâ by V. Balijepally, et el⌠In conclusion, pair programming cannot exceed the performance of its best members working individually.
p. 106
The pair is like a driver and navigator. On on the keyboard, the other telling them what to type. Roles should reverse regularly.
Advertised benefits:
Thereâs a caution about romantic pairing not being great for the team (but good for the pair).
Most people think pairing will essentially halve the output. XP proponents respond that if the pair produces software that is twice as good, it is a productivity gain, not a loss. Typical productivity figures in software industry, measured in source lines of code (SLoC), are around 20 SLoCs per person per day. Clearly, the rest of the day is thinking and correcting.
Empirical studies fail to give resounding answer of support for pair programming.
Mentoring is good. However, mentoring and pairing cannot be combined. The Jr. memeber will slow down the senior, who instead of getting help for most difficult challenges, finds themselves repeatedly explaining the easiest parts. And the teacher, facing a deadline, will not explain more than strictly needed.
Pair programming is meant to obtain feedback from someone around the same level of skills.
Mob programming is all of the brilliant people working at the same time, in the same space, at the same computer, on the same thing. I mean, is this real?
We should remember immortal works, â[We should be] mature enought to separate approval from arousal.â
Pair programming can be useful. However, XP advocates this as the only way to program, which is absurd:
Agile view is that communication should be encouraged, and the days of solitary, silent genius are gone.
It is dangerous to force a single work pattern in a highlly creative and challenging intellectual endeavor.
With some practice, it should be hard to impossible to tell who wrote what code on a team. This means that everyone is following the same standards. This idea was coined in the 1970s as âegoless programmingâ.
p. 109
Refactoring is the alternative to big upfront design. It involves sucessive versions of the program, looking for design and code âsmellsâ, and correcting them.
One typical example of code smell is duplication. Typical refactoring is to abstract commonality into separate module. Programmers perform refactoring by identifying code smells and implementing a refactoring pattern if one exists and is applicable.
Refactoring: clean your code has some cool tips and techniques, perhaps for another day. This blog from Common Refactoring Patterns and How to Use Them | Refraction also covers some common refactoring patterns.
Refactoring is different from update because of these 2 promenent properties:
Refactoring is not bug fixing. Basically, code and design smells are signs of bad quality, which may be refered to as âanti-patternsâ.
Overall, aim for simplicity, no duplication, minimum number of classes, minimum number of methods.
Benefits of refactoring?
Limits of refactoring
Take refactoring in small steps. If in the middle of a test case, move a method or variable to clean up.
Remember that Garbage In, Garbage Out (GIGO). Refactored junk is still junk.
p.112
2 ways initial design can lead to imperfect architecture:
This distinction is related to the additive vs multiplicative complexity noted earlier.
Refactoring cannot correct a flawedarchitecture. Primary responsibility of any designer is to identify the fundamental abstractions that will provide the backbone of the architecture.
Agile methods teach us that we should always be ready to criticize our own work, and alert to code smells.
p. 113
Test Driven Development (TDD) is technical practice of testing before developing.
Itâs not a testing technique, but a software development method. The basic cycle:
4 major implications:
Criticism:
Benefits: Not discussed but iâm sure you can figure it out ;)
p. 117
Main virtual artifacts: working code, tests, user stories, story points, velocity, definition of done, product backlog.
Concrete artifacts: working space, story card, task and story board, burndown chart.
Negative artifacts to avoid: impediment, technical debt, waste, dependencies, dependency charts.
Specifically, working code.
Two core artifacts here:
Unit test is description of particular test run and its expected results. For a unit test in the âxUnitâ style testing tools, such as JUnit for Java, it takes the form of a class and includes:
The regression test suite is a collection of unit tests. It should include any test that has been found to fail at some point. That is because, a particular phenomenon of software development is that old bugs tend to reappear. This may be known as software regression. Note, this doesnât have to be only tests that previously failed.
Regression test suites are a key asset to any well-managed software project. These are also incremental by nature, starting small and (hopefully) growing with the project.
User stories provide the basic unit of requirements in Agile methods. It is the description of a fine-grain functionality of the system, as seen by users.
A more general notion is the use case. This can be big, describing an entire interaction scenario, like the process of ordering an item on a website. I think they may also call these epics?
The standard style that emerged in Agile circle to describe user stories consists of a triple: category of user, goal, benefit.
You canât just list a change like âupdate database from relational to no-SQL solution.â You must define it as a task for a user story that describes a benefit visible to users.
Benefits of relying on user stories as basis for development:
Note that the size of a user story does not necessarily translate to its complexity. Itâs normal for different user stories to take different amounts of effort. That is why we measure them up with story points. Story points are a measure of effort, which will be discussed in just a bit.
Lack of perspective can lead to a brittle design and overall useless work, waste. Mention of domain model, which is a model for real world properties. You can avoid duplicate code by working on the domain model first, and making it in a way that supports different user stories.
Looking at the whole problem rather than individual details is Lean software principle.
Infrastructure work in not glamorous and shunned in Agile approach because it does not immediately bring new user-relevant visibility.
Just like how tests cannot replace specifications; user stories cannot replace requirements and designs.
The dual development technique was introduced previously, but I believe it is working on infrastructure and delivering working systems regularly, either in sequence or parallel.
p. 121
Successful project control requires:
For both of these techniques we require a unit of progress. Traditionally, the industry used person-months, or person-days, but is more about cost than effort. Source lines of code counts (LOCs, SLOCs) are also used. However, it is difficult to measure in advance the SLOC count of a system.
A better measure is function points, estimates the number of individual functions of the system. However, hard to estimate, and not always appropriate in developments using modern object-oriented techniques.
In Agile world the basis for measuring progress comes from the standard mode of specifying functionality: user stories. We donât count user stories, but give each story a number of story points. The beauty of this is that estimating with story points separates estimation of effort from estimation of duration.
Story point have 3 important properties:
Story points are kind of new. XP used an absolute measure of time, ideal programming time, which was days required to implement a story assuming full-time work with no distractions. That as weighted by a load factor, ratio of actual time to ideal time, typically 2 to 4. But this was criticised to fudge the estimation, so XP moved to âpure programmer weeksâ. Then the trend to abandon the reference to precise units of time and work with a dimension-less number.
The term gummi bear is sometimes used as a synonym for story points.
Planning Poker is one of the accepted Agile techniques for obtaining story point estimates for user stories.
p. 123
The cost estimates given to user stories can be used to assess progress when the iteration starts. Velocity is a way to provide âa clear, measurable, continuous estimate of the speed at which a project is progressing.â Iâve heard it a few different ways, but the saying goes like, âIt takes 20% of the time to get 80% done, and the remaining 80% of the time to get the last 20% done.â
Or, âYou can achieve most of the work in a fraction of the time, and then spend the rest of the time perfecting the details.â
Or, âAchieving 80% completion requires a mere fraction of the time, while the remaining 20% necessitates a substantial portion of the total time investment.â
The physics definition of the vector velocity is distance per unit time. For Software Development, itâs more like story points per iteration. Basically, itâs hard to accurately predict how long projects take. However, by applying the story point methodology, the relative predictions of story points should become more accurate over time.
If you donât know how to create story points, check out this Asana Guide through applying story points with the Fibonacci sequence story point matrix. Or use a search engine or your favourite AI chat bot for more information.
p. 125
The Definition of Done is apparently a Scrum concept of knowing what everyone means when they say they are done. The definition is also important to fairly and accurately measure progress. Some ideas for definitions:
p. 125
XP argues group programming in open spaces, called bullpens, fosters communication. XP also recommends people have small cubbies along the outside communal space they can keep their belonging in and have a false sense of privacy.
Thereâs a huge push toward âeveryone-under-one-roofâ model, stating that it is better. I understand that it might be good for many people, but I personally believe it to have a negative impact on my productivity and mental health due to lack of privacy and stress from being an introvert.
p. 126
In software engineering, a requirement means the description of a property of the system. And the requirements refers to the overall description of the system. However, Agile approaches reject traditional comprehensive requirements documents, typically cited as waste. Instead, Agile prefers:
Scrum recommends dividing backlog into 3 parts, containing respectively the user stories or tasks for:
These are malleable recommendations.
p. 127
These are physical note cards with hand-written user stories.
p. 127
Visible reminders of tasks to do, in progress, and completed keep the team on the same page. Team members can pick up tasks when needed, keep track of velocity, and discourage waste. Things that donât deliver functionality arenât shown on the board.
A Task Board was usually a physical whiteboard with magnets and index cards. However, there are countless software applications that can serve as an upgraded replacement for the physical artifact.
p. 128
A burndown chart is a visual graph of velocity, that is remaining tasks / story points over days in iteration. The idea is that remaining story points should decrease over time.
In the Crystal Agile methodology, they use burnup charts that shows progress instead of work remaining.
Both graphs have these similar properties:
p. 129
An impediment is âany matter that damages the progress of the project, whether technical or organizational.â
p. 129
These last artifacts are considered negative artifacts and are suggested to be avoided in Agile circles.
For the Lean Agile methodology, it is all about avoiding waste. Waste is considered anything not delivered to customers. That means things like design documents are waste and say unfocused meetings are also waste.
Technical debt refers to code elements of poor quality. Initially they are hardly noticeable, but as they accumulate they cause issues. Refactoring is the tool for fighting technical debt.
Dependencies are constraints between development elements. The word is self describing. Dependencies prevent the Agile practice of developers picking the next task on the iteration backlog to develop.
There are also developer constraints. The goal is for a cross-functional team. However, people often have areas of expertise and are better suited for certain tasks. Sometimes it is best to wait until they are available to handle certain tasks.
The final artifact we will discuss is a dependency chart. Often these take the form of Gantt Charts. Remember that accurately predicting task and project durations can be difficult. So, creating a whole chart is probably a waste of time as it will probably need updates within days and on a continuous basis.
Rejecting all of this waste is an extreme approach. However, remembering what is considered waste might be helpful.
p. 133
Reviewing key characteristics of the four main methods cited in this book.
p.133
Methodology is the study of methods. So a method is something being studies. Often, it is seen Agile methods denoted as methodologies, are acceptable as a combination of methods.
The author is looking for the One Big Idea behind each method that supports all other method components. Each method consists of principles and practices, hopefully stemming from that big idea. The author will then provide an assessment of the method.
p.134
Lean and Kanban came from mostly Toyota. Feel free to research on your own.
Leanâs big idea is to Reduce Waste. Waste, as described above, is anything not delivered to the customer. The aim is to focus on what matters to the customers, and remove distractions.
Lean Software method promotes 7 principles:
Not a âcradle-to-graveâ method, but more of a philosophy from a set of general observations. Donât turn to Lean Software as a comprehensive software development method or expect everything from their text to be absolute. However, their contribution to the community has been significant.
Kanban is distinct from Lean Software but also draws from the Toyota production process. Kanbanâs big idea is to Minimize Work in Progress. The Kanban board is similar to the Scrum task board, used to visualize progress. However, thereâs not actually an explicit Kanban method for software, but its principles are useful.
p. 137
Extreme Programming (XP) is the original Agile approach with an introduction in the late 1990s.
Itâs big idea is to Increment then simplify. Functionality is added through test-driven-development and refactored to restore simplicity. Thereâs also the pair-programming initiative.
There are a few texts written, but the original reference is Beckâs âExtreme Programming Explainedâ. The author continues to explain how they preferred the 2000 first edition of the book to the 2005 second edition, as the latter was more of a response to criticism and toned down the simplistic and in-your-face style in favour of a more abstract teaching.
The XP books have very long lists of practices. However, some essentials are:
Extreme Programming (XP) is an approach to software development that brought attention to agile methods. The term âextremeâ emphasizes the idea of taking the best development practices to their fullest extent. XP is known for being assertive and seeing its techniques as obligations rather than options. For example, it advocates for pair programming, where two programmers work together on the same code. This assertiveness has both strengths and drawbacks, as it has limited the overall adoption of XP in the programming community. However, many individual techniques promoted by XP have made a significant impact in the industry, even outside of agile processes. XP has particularly highlighted the importance of two techniques: continuously integrating code by avoiding code branches and consistently testing software. These contributions alone have secured XPâs place in the history of software engineering.
p. 139
Scrum has taken over as the Agile method of choice. There are many texts about principles and practices.
The author states the big idea for Scrum is to Freeze Requirements During Short Iterations, also referred to by the author as the âclosed-windowâ rule. There are many other concepts like the 3-roles, 4-events, pigs and chickens, etc⌠But this is the core that addresses how to handle change.
List of Scrum practices, discussed previously as well:
The iteration model, called the sprint, has become the industry standard. Scrumâs primary contribution affects the organizational aspects of projects, and can be generalized to apply to non-software technical disciplines. Does this mean thereâs room for an Agile method that takes the best from Scrum and addresses unique demands of Software Development?
p. 141
Crystal actually refers to a 2-D array of methods based on criticality and size, each characteristic having four levels.
Crystalâs big idea is Osmotic Communication, or communication through the team as a single unit. Because older generations can only comprehend communication in person, the focus is on office space layout that favours open communication. This Agile method treats poor communication as the core issue of software development. Projects can face major costs and impediments from bad communication between team members, delays in answering questions, and questions just not asked for whatever reason.
Crystalâs 7-principles:
Crystal is not a comprehensive method or a step-by-step guide. Itâs more like software development wisdom. Some distinguishing characteristics is refusal of dogmatism and acceptance of some classical software engineering principles.
p. 145
p. 145
Software engineering has laws that limit what we can expect. Boehmâs work in the 1980s has been confirmed by numerous studies. It states for any IT problem there exists a ânominalâ cost and a nominal development time, and solutions cannot deviate from them. Sounds similar to the iron triangle; to speed up development time you will spend more money and decrease product quality, or something of that nature.
These are not laws of physics, but observations supported by credible empirical studies.
p. 146
Iterations in Agile Development are time-boxed. When something must give, it would be features over the iterationâs end date. However, customers may note negotiate as easily. Your man Beck suggests taking a huge contract, and trying to split it up into several smaller ones.
Many customers want to know both âwhenâ and âwhatâ. In transitional environments, plan-oriented groups can find it hard to get precise commitments from Agile ones. The difficulty of getting Agile teams to commit is a delicate issue. Itâs best to split goals into intermediate steps, define tangible objectives that can be achieved at regular intervals.
p. 149 #here