Category Archives: Agile

Running A Sprint Planning Meeting

Agile, Idle Speculation, Internet Culture, Nostalgia, Programming, Teaching, Thoughts on Thoughts

It’s the little things that sometimes make a difference. When I was teaching standardized test math so many years ago, I noticed as I was drawing problems on the board, all the little habits that I had picked up. Habits which make solving problems easier, habits which reduce the chance for error.

Things like the curve on the leg of the lower-case ‘t’, so that it doesn’t look like a ‘+’. Curving your ‘x’ so it doesn’t look like a ‘*’ sign.

I think some of this (probably sometimes annoying) attention to detail had carried over to Sprint Planning meetings[1].

Planning Poker is a method for a group to converge on a time estimate for a task or group of tasks. There are a number of ways to do this. The ‘canonical’ way we were taught to do this was to use Fibonacci-numbered cards (1,2,3,,5,Eureka!). This involved a discussion of the task(s) to estimate until everyone had a reasonable idea of their complexity, then each person would choose a number estimate, all of which would be revealed simultaneously, to hopefully reduce bias. The discussion before estimation would not include estimates of how long things were estimated to take, to also try to reduce bias.

While we were running our planning meetings, I noticed that we would start to slip away from this ideal, perhaps because certain things were not important, perhaps because we didn’t see that certain things were important. For example:

We moved from cards to apps, and then to fingers. Using apps for estimation is less annoying than finding the cards each time, but fingers are even faster to find. I/we tried to get around the bias effect by having everyone display their fingers at once, and that worked reasonably well. Even making each person think about their estimate before display can help a lot with reducing the impact of what others might think of them.

One thing I tried which never really caught on when other people were running the meeting was saying ‘A,B,C’ instead of ‘1,2,3’, with the idea that it would be less biasing on the numbers people were choosing. (This may have mostly been an impression of mine, as the moving of the estimate from a mental number to a number of fingers may cement it in a slightly different mental state…)

If one is not careful, and perhaps somewhat impatient in meetings[2], one can start suggesting estimates before they are voted on. It can take considerable discipline and practice to not do this.

Another thing I noticed was how difficult JIRA was to use when one is not practiced in it, especially in a room with many people watching. Something that any experienced[3] demo-giver would know like the back of PowerPoint’s hand.

That’s all I have for now. For more minutiae, tune in tomorrow!

[1]For those of you who have not had the pleasure, these are the meetings at the start of an iteration, where the team sits down in a room, estimates a bunch of priority-ranked tasks, and decides (generally by consensus) how many of them they will commit to getting done in the next two weeks. Like all meetings, they can be good or bad, and the meeting chair (I feel) can make a large difference.

[2]I am probably as guilty of this as anyone. I would recommend Randy Pausch’s ‘Time Management‘ for those who feel similarly.

[3]Read: ‘Battle-scarred’

What are your Non-Negotiables?

Agile, Idle Speculation, Organizing Systems, Programming, Thoughts on Thoughts

What are your Non-Negotiables? Most recently, I was talking to someone[1] about my New Year’s resolutions, and we were discussing why I had done one of them, but not the other two. It eventually came out that the resolution that worked (writing every day this year[2]), worked because I had made it a Non-Negotiable[3]. I had resolved that no matter what, every day this year, I would write something. Somehow, every day, I would carve out an hour or two, pushing other things aside so that I could focus and write.

(Incidentally, this practice focusing has done wonders for me, helping me find ‘the zone’, or ‘flow’ much more consciously and easily.)

Sometimes I would push aside a computer game, or facebook, sometimes sleep, but those things didn’t matter compared to the commitment I had made (mostly to myself) to write every day.

Interestingly, the other Non-Negotiable that came to mind today was the 5-minute standup. I was talking to someone about it today, and they started to say ‘5-10 minutes’, and I had to interject, with talk of Non-Negotiables, how if you let something like that slip, pretty soon you’re having daily half-hour sit down ‘stand-up’ meetings.

Interestingly, biking to work every day is not quite a Non-Negotiable. I take probably a couple of weeks off each year, some for snow, some for rain, some for events. It’s pretty close, though, and I’m not so worried, because I’ve been doing it for long enough (14 years, I think), that it’s a pretty deep-seated habit.

So, what are your Non-Negotiables? What is the one thing you want to change this year?

[1]Pretty sure it was G at a life coaching session, but my brain has this annoying tendency to abstract things away, but that’s another post. I also remember it from a speech by the head counselor at music camp many years ago, but that’s another story…

[2]At least so far…

[3]This is a good precis from a life coach on Non-Negotiables.

Silos and Agile Project/Product Management

Agile, Idle Speculation, Software Development

Earlier this week, I was talking with a friend of mine who had been recently promoted from Scrum Master/Product Owner[1] to being a project/product manager[2].

The issue they were experiencing was that they had a number of teams (think 10+), each of which was producing a good product, but the product as a whole was terrible. Also, the last time they tried to assemble a team to deal with this, it foundered because of intense opposition and inertia.

So, how do you deal with this, especially as a product manager in charge of the whole project, with no direct reports[3]?

We ended up almost working backwards to find a solution. When they were on a team, their sideways management[4] style was to learn how each of the people tick, and to help fit them with doing the work that was best for them.

My first idea was to have a working group with a member of each of the teams, where they would work together to make all the parts work better as a whole.

To me, this felt like it was iffy, and could easily be torpedoed by a small number of people obstructing it, or even not being engaged.

So, we came up with something simpler. In any project of this size, there must be some more obvious pain points, and some people who are more interested in collaborating to solve them. So, you just need to get a few people in a room together. Maybe only two. You find a few quick wins where they can quickly show the benefits of working together. Maybe the things they’re working on are even useful to their own teams.

To me, this is really using the Agile principles the way they’re supposed to be used. You find the most obvious problem, find a small number of people who are most interested in solving it, get some quick wins, and then spiral out from there.

We’ll see how well this ‘Agile from Below’ worked. Here’s hoping.

[1]This is how they described it, but didn’t go into detail, and I might have misheard it. If true, I’m not sure how this would work in practice, perhaps as a counterweight to supervisory management?

[2]They described it as one or both of these, and the role described above could be defined (as far as I know) as either. Thinking about it some more, it feels more like a product management role, which is how I decided to write it above.

[3]That you can direct. Ha!

[4]I use ‘sideways management’ to mean things positions like ‘Scrum master’, where your job is to remove blocks from people who don’t report to you.

Agile: Limitations of Scrum

Agile, Programming, Thoughts on Thoughts

Based on some recent experiences and conversations, I wanted to explore a couple limitations of Scrum that have come up recently.

1) Limitations of the Standup

Long-time readers will know that I’m a strong advocate of the 5-minute daily standup.

Where 5-minute daily standups are weak is in any discussion of the larger picture. If you try to have a reasonable discussion about the larger picture during a 5-minute standup, this will take far more time, and most of your group will have tuned out by the time you’re done. Conversely, under normal operation, your 5-minute daily standup is great at firefighting issues with currently open tickets, and seeing what is not being worked on, but unless you’re paying active attention, it’s easy to miss someone being semi-blocked or not speaking up to say that they’re blocked. This can happen often due to pride or embarrassment, often with inexperienced or new team members.

Proper use of one-on-ones is probably the best way to deal with this. But if your team member is shy and embarrassed about issues they’re having (especially if they feel technically inadequate), you may need to do some serious digging and active listening to ferret this out. This will require, but also help gain trust of your team member.

Another method is to have regular demos, perhaps daily or weekly, as part of your cadence, which will very quickly show who is having issues (or who does not know how to demo).

2) Limitations of having many small tasks

Organiation and prioritization can be difficult and time-consuming. It can often be easier to delegate all of it to the Product Owner (after all, they have final say on prioritization). However, they may not be the expert on which items should be split into smaller items, or they may try to determine too much of the ‘how’, instead of focusing on the ‘what’ and especially the ‘why’.

What this can cause is a disconnection between the ‘why’ and all of the rest of the team. The work can start to feel like an endless stream of little unimportant tasks, rather than a cohesive whole.

My tactic to deal with this would be to have a planning and prioritization session with everyone attending, so the entire team can be and feel involved, and so the entire team understands the why of each of the items (and can influence which ones will be done and not done!)

I was talking to a manager from another company earlier this week, and they had (I thought) a good idea for dealing with this type of issue. I would typify it as being somewhat orthogonal to Scrum, perhaps somewhat orthogonal to Agile. The concept is to give each member of the team a project of their own, where they are completely in charge. This way, they have complete ownership, and ostensibly will be much more engaged. I like this idea, and it helps a lot with the next point:

3) Scrum works well when team members are well-fungible

A lot of Agile and Scrum especially assumes that team members are reasonably fungible, sometimes almost to ‘Mythical Man-Month’ levels. If you have team members who have vastly different specializations (like Valve’s ‘T-shaped individuals'[1]), your prioritization may be greatly limited by their inability to map to your team members’ strengths.

The tactic mentioned above, where you give each team member a small (or large!) project of their own can help a lot here, but depending on how much of a disconnect you have between the composition of your team and what your organization requires, you may need to hire some people.

[1]If you have not read Valve’s Employee Handbook, go and read it now. I’m talking above about their description of employees who are ‘T-shaped’, which means that they have a broad set of skills, but are exceptionally deep in one area.

Better Conference Calls

Agile, Software Development, Thoughts on Thoughts

So, I was talking with A earlier this week about meetings, and she mentioned the issues that many people have with conference calls.

But what are those issues? I can only talk about issues that I’ve had with conference calls.

For those who are not familiar, we’ll start with audio conference calls.

A humorous video by Tripp & Tyler may help illustrate.

To me, these problems can be broken down into the following categories:

Human factors:
– Absence of body language
– Outside distractions

Technical factors:
– Lag
– Other audio artifacts of VOIP
– Technical issues with audio conferencing software

We’ll start with the Technical factors.

Lag:

Lag feels like it’s only gotten more prevalent with greater use of mobile phones and VOIP. Of the two components of lag (encoding/decoding time and routing/travel time), you can probably improve routing/travel time the most by spending more money on better dedicated VOIP connections. You may also get some mileage from having your conferences during off-peak hours and being on a wired (rather than wireless) connection. The anti-jitter algorithms described in this ‘how VOIP works’ article inherently have a tradeoff* between jitter/dropout and lag. If you make things easier for them, they should be able to improve both for you.

Other audio artifacts of VOIP:

These other audio artifacts are also products of the packet data nature of VOIP. ‘Toilet bowl audio’ is caused by VOIP losing packets and the sound being recreated artificially by the algorithms. (Before they figured this out, you would hear pops or crackles or even more annoying sounds, like in early mp3 encodings.) Sound cutting out is the result of too many consecutive packets being lost.

Feedback is an interesting one. I’ll use the iPhone as an example. When you have the speaker on a device very close to the microphone, you’re liable to get feedback. The device gets around this by analyzing the sounds coming in through the microphone, and ‘subtracting’ them from the output stream. The echoes you may hear sometimes is what happens when this fails. These algorithms were required to make satellite communications viable.

(A better history of echo cancellation is here, for those who are interested: ECHO_history_of_echo_cancellation )

Other audio artifacts of VOIP have similar origins and solutions.

Technical issues with audio conferencing software:

This one still puzzles me. Like microwaves, they seem to be all different, and none of them intuitive. I can’t tell if this is because the industry has not converged on a solution, or the problem is actually that unsolveable. My current favourite is Google hangouts, but that could be because I generally use them for one-on-one conversations. Perhaps this problem is because of the always problematic nature of security, when controlling access of people to be able to phone into a conversation. But even when there is no conference call security, there are still always issues, with people trying to call into the conference, calling the wrong way. I feel like the solution is to have an intuitive interface, where you can see all the calls coming in to your phone and then drag them together to make a conference.

We could even make a game of this. We could call it ’21st century switchboard operator**’.

Now, on to human factors.

Absence of body language:

This is a tough one. Interestingly, humans figured out a method for showing body language in text at most 11 years after the first email*** was sent, while 140 years after the invention of long-range audio communication****, we still do not have an effective method of conveying body language over audio transmissions. I would say that video conferencing will supplant all audio within our lifetime, but there is still space communication, satellite communication, dark rooms, non-working cameras, etc… Perhaps some sort of interstitial click language would work.

In the meantime, the best solution is to have people meet each other, in person if possible, over video or at least a one-on-one audio before they engage in a conference together.

The other elephant in the room is people who are normally bad at in-person body language cues for when it is time for them to finish talking. In person, this can be difficult, even with a strong moderator. In an audio conference, this can be well nigh impossible. A moderator with the ability to selectively mute participants might work. The social hierarchies in many organizations may not permit this, but improving the flexibility of those hierarchies and teaching people to *listen* is one of the key components of Agile.

Outside Distractions:

This one feels like a tossup between having a strong moderator and having an engaged workforce. Sometimes life does indeed intrude into work, but if this is occurring on a regular basis, perhaps it’s an indication that the meeting is at the wrong time, or too long, too low a priority, or the participants are not as engaged as they could be, for whatever reason. Addressing those issues is probably the best next step here.

So, that was a lot of words. Apparently I have a lot of thoughts about this. If you want more, comment below!

Some other useful links:

An explanation of packet loss and discards.

*Because you’re sending voice data in packets, these packets have to be reassembled at the other end. Because the packets are going over the internet, they can be delayed. A delayed packet either has to be left out or waited for. This causes jitter and lag, respectively. If you have a better connection, the algorithms can make better decisions for you.

**This just makes me appreciate the people who did this job even more, and I always thought it was difficult.

***The article also goes in depth about the specific strengths of email, and how it may be a more natural method of communication for humans than some other types…

****I did not know before reading this article that Alexander Graham Bell was “Professor of Vocal Physiology at Boston University [and] engaged in training teachers in the art of instructing deaf mutes how to speak”

Focusing Meetings

Agile, Idle Speculation, Organizing Systems, Software Development, Thoughts on Thoughts

What kinds of meetings do you actually need in an organization? I don’t really know the answer to this. What I do know are the meetings that work for me on an ongoing basis. I would call my process ‘Scrum-like’, in that I think it takes the best features of Scrum, but I’m sure I’m not doing it exactly by-the-book.

1) Daily 5-minute standups. When I say ‘5 minutes’, I mean 5 minutes. I have said much more on this here: http://nayrb.org/~blog/2016/01/15/the-5-minute-standup/ They keep people up to date, and should spawn whatever conversations you need to keep things flowing

2) Bi-weekly* planning and retrospective meetings. You may be able to get this down to 1 hour every two weeks for both if your team is well defined and has been working together for a while. You may need an hour each plus one hour for backlog grooming every two weeks. Again, depending on how defined the work is that your team is doing, YMMV.

3) One-on-one weekly meetings with each of your direct reports. Long term, probably the most important of any of these. This is where you find what is actually happening, how your people are actually feeling. ‘Managing Humans’ by Michael Lopp has multiple chapters on this. Fundamentally, you want to establish trust with your reports. This includes listening, asking them about what they want (both now and in the future), followed by more listening, then following up to actually get them what they want and need as much as you can.

4) Broadcast meetings. I’m talking about town halls, other meetings where you want to get news out to a lot of people quickly. Best to keep these reasonably short, and choose your most interesting public speakers. If you have a CEO that can hold a room and answer questions, this is a great opportunity for them to shine. Many of these meetings can be avoided by a fanout leading to 30s announcements by leads in your daily standups (or email).

5) This last category is more fuzzy. It includes all those meetings outside your regular schedule. These are generally a mix of long term planning meetings (vision/strategy/etc…), short term planning meetings (figuring out what we’re doing with this project so we can make it into bite-sized tickets), and unblocking meetings (this project is behind, these people disagree, this thing you want us to do is physically impossible, etc…).

It is this fuzziness that that can be the death of a meeting. The first four types have pretty defined schedules and agendas**. This last type is pretty free form. Here are some things we’ve found that help:

A) Make sure the meeting is ‘Ready’

In Agile, there is the concept of a ticket being ‘Ready’, where before someone starts work on something, that something has to reach a certain level of definition. Generally, this would include things like ‘Acceptance Critera’ (how you know it’s done), and a ‘Why’, ‘What’, and some idea of ‘How’ you are going to do it***.

For our meetings, we had a pretty simple of ‘Ready’:
– Someone is in charge of running the meeting
– The meeting has a stated purpose
– The meeting has an agenda

B) Make sure the person**** in charge of running the meeting can run a meeting

This generally means:
– They are familiar and can follow the purpose and agenda described above
– They can tell when a conversation is going off topic or over time
– They can bring the conversation back

This last point can be as simple as ‘in the interest of time’. Having a written agenda on a whiteboard or flipchart can help a lot with this. If you include time allotments, this will give your meeting runner something to point to to get people back on track.

C) Have plans for action items

– Assign action items

Often, this is the role of the meeting runner (chairperson, really), but could be some other person in the room with the gravitas/authority to persuade/compel people to do the required/decided on things.

– Track action items and follow up if necessary

You want the follow up assignments to be in a place where everyone in the meeting can track their progress (whatever ticketing system you have is ideal, or perhaps whatever wiki system your organization uses).

– Avoid a further meeting on this topic

Depending on your particular participants, someone may need to be assigned to follow up, or it could be ‘homework’ for the next meeting. Ideally, you want to make these meetings as infrequent as possible, so subsuming the action items into your regular ticketing and tracking system is ideal and obviates the need for a specific follow-up meeting.

And that’s it! If you follow these simple steps, your meetings should be much more focused and productive!

Let me know what you think in the comments (as well as if you want me to delve deeper into parts of this).

*I say bi-weekly because we do two week sprints. YMMV.

**If you want me to talk more about agendas for planning meetings, retros, one-on-ones, and broadcast meetings, I can do so, but this is out of scope.

***The exact contents of this definition of ‘Ready’ are generally defined on a team-by-team basis.

****There are a bunch of specific skills here which are out of scope. Comment if you want more on this.

The 5-Minute Standup

Agile, Organizing Systems, Software Development, Thoughts on Thoughts

Many people have written about daily standups*, and many people have written about the benefits of short meetings**.

I want to talk today about the idea of the 5-minute standup. This is an evolution of the daily standup that is part of the Scrum*** Agile methodology. I’m writing this from a Development perspective, but this could just as easily be applied to many other types of organizations.

The purpose of the daily standup as I see it is twofold:
1) Let everyone know what everyone else is working on
2) Let everyone know when someone is in trouble/blocked, so they can help

Classically, the daily Scrum standup has three questions:
A) What did you do yesterday?
B) What are you planning to do today?
C) What is blocking you right now****?

In my (limited) experience, people are pretty good about the status update part of things (what did you do yesterday?), and the forecasting part (what are you planning to do next?). You may need to explicitly ask the blocking question for a while until your team fully trusts you and the rest of the team to listen to their (often embarrassing) blockers and actually help them.

For me, I’m very much a proponent of short meetings. I love being as concise as possible (Think Ulath*****). I have an acute sensitivity for people who are uncomfortable with a situation or have checked out, and I try to do everything I can to fix that. (This makes me a good host, but it can be very tiring.) If I’m running a meeting, it will have a defined purpose, and it will be only as long as it needs to be.

I’ve found that developers especially will check out of a standup within minutes. Having a meeting of 5 minutes or less was the only way I could find to keep people engaged in a status meeting.

The way we’ve found best to run these meetings is to have the current set of tickets up on the screen, and we go through them in order. People are generally only working on one or two at a time, so it’s effectively the same as going around the circle, but with the added benefit of the visual aid. You can also do all of your ticket status changing at this time, along with asking for code reviews. Anyone who was missed then gives their update, then you break out to whatever after-meeting conversations were deemed necessary during the meeting. This way, only the people who need to be in those conversations are, and everyone else can get back to whatever else they were doing.

Some tips:
– If you find your standups routinely taking longer than 5 minutes (or 1 minute per person, max 10 people in a standup******!), try giving the most ‘detail-oriented’/rules-based person on your team the timer, and telling them to give each person no more than 1 minute to talk. It worked wonders for us. (I often do this myself, by being the most impatient one in the meeting.)
– Announcements should happen very quickly (max 30s), or over email. Discussions can happen after the standup is over.

To Recap:

Pros of the 5-minute daily standup:
– Less time
– No time spent on details, just high level, in depth discussions pushed to smaller groups
– Devs are much less likely to check out
– Not dreaded like interminable meetings
– A good outlet for the detail-oriented member of your team who cares about process, and wants to time things

Cons of the 5-minute daily standup:
– Still takes devs out of the flow, distracting them for much time before and after
– You still have to have all the one-on-one meetings to resolve things afterwards…
– It can make you think you’re having full communication when you’re not

*Interestingly, this is a very old tradition, as the UK privy council only has meetings where all members stand https://en.wikipedia.org/wiki/Privy_Council_of_the_United_Kingdom#Meetings

**Randy Pausch gave an excellent lecture on Time Management https://www.youtube.com/watch?v=oTugjssqOT0 and the benefits of making meetings as short as your scheduling software will allow.

***https://en.wikipedia.org/wiki/Scrum_%28software_development%29

****Many people would say “Is anything blocking you right now? I mostly avoid yes or no questions, as they’re too easy to dodge with a one word answer, and a lot of having effective meetings is getting people to be present and trust you and not dodge.

*****http://davideddings.wikia.com/wiki/Ulath

******If you have more than 10 people on your team, your team is too big. Note that more than 10 people can be listening or watching, if they also want an update, but there should be no more than 10 people talking, at 1 minute each.

Agile: Scrum, Kanban, and Beyond

Agile, Idle Speculation, Organizing Systems, Software Development

Scrum* is arguably the most popular of the Agile methodologies. It seems to be popular because it is lightweight while being structured. However, it is designed to interface with and compensate for the structural issues inherent in most large organizations.

The end goal of all Agile methodologies is to ship the greatest amount of useful, high quality software at a sustainable pace.

Scrum assists with this in the following ways:
– The ‘locked room’ iteration reduces or prevents distractions so the team can focus on their work.
– Requiring stories to meet specific, defined criteria in order to be ‘Ready’ or ‘Done’ adds clarity and reduces time wasted in clarification
– Channeling all outside asks through the Product Owner reduces distractions for the rest of the team
– Having the team perform the estimates provides a sense of ownership
– Having subject matter experts on all relevant subjects and from all relevant departments in the organization reduces the amount of time the team spends waiting for clarification
– Daily standups

There are more, but I think you get the point. Scrum is all about reducing distractions and time spent obtaining clarifications. Scrum also uses the crutch of iterations of a defined length to help reduce distractions from the rest of the organization, to help outside stakeholders get used to the idea that creating software takes time, but more importantly, to get outside stakeholders used to the idea that context switching takes time and has a cost.

I call the defined iteration a crutch, because there is another Agile methodology which does not have fixed iterations. I’m talking about Kanban, which is very similar (at least in my experience) to what I described above for Scrum, except that instead of Scrum’s timeboxing tasks to two weeks, Kanban focuses on enforcing a limit on the amount of work in progress.

For teams outside of operations and firefighting**, this requires more trust between the team and the organization, and likely a much more persuasive Product Owner to interface and control the conversation with the rest of the company.

But requiring a Product Owner to do this interface still feels like a crutch. What if everyone in the organization just knew what to do, and you didn’t need to separate out wrangling over priorities in order to stop distracting programmers?

Valve seems to be doing this:

http://www.valvesoftware.com/company/Valve_Handbook_LowRes.pdf

Their ethos is that they once a person has gotten through their very intensive hiring process, they are empowered to make all the decisions required to ship products. They seem to have found a way to gain the benefits of Agile without all of the crutches of the methodologies above.

We will explore more of this, and some possible steps in a future post.

Comments and topic suggestions below!

*In all of this, I am making the assumption that the team is running Scrum by the book. There are numerous obstacles to this which are outside the scope.

**Many operations and firefighting teams naturally gravitate more towards a Kanban approach than a Scrum approach, as they tend to have more volatility in their tasks, and possibly smaller tasks are required to make outside-world-visible results.

Agile Power Dynamics

Agile, Analysis, Software Development

In a previous post*: http://nayrb.org/~blog/2015/12/31/agile-basics/

I talked a little bit about Agile and what I thought it meant.

Today, I want to talk a little about how decision-making power is different in an Agile world.

Fundamentally, for me**, ‘Agile’ is all about codifying some of the hard-won lessons from the first 55*** years of computer programming.

There are a number of interlocking ideas in the manifesto, and I keep finding new wrinkles to them when new situations arise, so I’m going to focus on power dynamics.

For this, I will need the strawman of ‘Waterfall’, the ‘development method’ most often contrasted with Agile. Most people represent ‘Waterfall’ as a number of time-sequential silos, with varying amounts of feedback between the silos:

waterfall_1_e96847237d43

waterfall-diagram-in-powerpoint

What is not generally mentioned about ‘Waterfall’ is that estimation is generally performed with minimal input from those implementing whatever solution is called for. This**** generally leads to time and feature estimates being imposed on those implementing the solution.

“You will be solving this problem, and it will take you 3 days to do it.”

It is probably not surprising then that large software projects are prone to cost overruns, as those doing the work are not generally involved in the planning process.

What Agile tries to do is to add and tighten feedback loops. Whereas in a ‘Waterfall’ process, you might release code every quarter, in an agile process, you might do so every two weeks, or multiple times a day.

Key concepts here are subdividing features into smaller and smaller bits, to make the smallest useful change each time, but do it very often.

Getting back to decision-making power, what Agile does is to separate Prioritization power from Estimation power.

Agile gives the Estimation power to the team that will be doing to work*****, while retaining prioritization power in Management. You say that it separates the ‘How’ from the ‘What’******.

This separation encourages more buy-in from staff, and can stop bad ideas earlier. Most importantly, it focuses each of staff and management on what they (theoretically) do best. Management is hired to make decisions about what should be done next, developers are hired because they know how to do things well[7*].

Next time, we’ll tease apart more of the manifesto.

*Same disclaimer applies: I currently work for a company. That company does Agile. From my limited experience, I think it does it well. I am not talking about that company in any way, shape, or form in this post.

**And many others

***I’m going from ENIAC, the first actual construction of a general purpose computer. Lest you think I’m forgetting about Ada Lovelace, you may want to read about the first six (all female) programmers of ENIAC: http://eniacprogrammers.org/

****There are also often issues of under-estimating the cost of things in order to obtain a contract/approvals, but this is outside the scope of this post. Suffice it to say that one who was singularly focused on landing a contract would have great incentives to ignore feasibility and estimation objections from those who might be implementing it.

*****Agile also tries to make sure that the team has someone skilled in every relevant part of the company, but that is outside the scope.

******The ‘Why’ is outside scope of this article. 😀

*******You are confident that your hiring process is bringing in good developers, aren’t you?

Agile Basics

Agile, Idle Speculation, Software Development

Disclaimer: I currently work for a company. That company does Agile. From my limited experience, I think it does it well. I am not talking about that company in any way, shape, or form in this post.

I don’t recall when I first heard about Agile software development. I probably heard about it from Slashdot, when I was still reading it during grad. school.

First up, the Manifesto itself:

From: http://agilemanifesto.org/

”
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on
the right, we value the items on the left more.
”

Overall, it feels like a very human approach to software development. I’ve always enjoyed speculating about the situations which may have led to rules being formed*.

It also feels like it was written by a group of people who were actually interested in solving problems, perhaps by cutting through Gordian Knots of rigid process and planning.

Their conclusion was that problems will occur, things will change, and you want your process to accommodate that as much as possible, to enable and encourage people to talk about these earlier and more effectively. More of a ‘getting to yes’, rather than rear-covering or posturing.

Now, they further broke down the above four statements into 12 principles:

http://agilemanifesto.org/principles.html

1) “Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.”

This one seems pretty self-evident, but there are a surprising number of people who have job descriptions at odds or orthogonal to this, especially as organizations get larger.

2) “Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.”

This might be the toughest (it was for me, and I consider myself good at this), as humans are naturally lazy and resistant to change.

Evolutionary Psychology : Laziness

I wonder if this can only be overcome through experience, by knowing how much more pain will happen if a particular shortcut is taken or some important stakeholder is ignored. (Even knowing that someone should be listened to instead of letting your lazy brain edit them out can be difficult.) Either way, a good argument for having at least one person (that you listen to!) with experience on the team.

But if you’re having requirements changing too often, your stories are likely not ready before you start, or they are too large, leading you to:

3) “Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.”

‘Fail early, fail often’ goes the quote. Coupled with 2), it becomes much more difficult to be working on the wrong thing when you’re allowing for updated requirements every time you start a new short story**.

4) “Business people and developers must work
together daily throughout the project.”

I feel like the people who put this list together had experienced a lot of communication problems where they worked. This one is really helpful. There are few things more annoying than being ready to work on something but not being able to reach the person who needs to make the decision.

5) “Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.”

From the people I’ve talked to, this is every programmer’s dream. All the best working environments I’ve been in have been like this.

6) “The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.”

Yes. And it drops off considerably, even to ‘face-to-face’ Skype/

7) “Working software is the primary measure of progress.”

Many people have different measures of progress, leading to organizational misalignment.

8) “Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.”

As much fun as ‘feast and famine’ is, you’re probably not doing your best work souped up on adrenaline and coffee. (Or maybe you are. If so, you should take some time off between binges.)

9) “Continuous attention to technical excellence
and good design enhances agility.”

‘We put brakes on the car so that it can go faster.’ ‘Legacy code is defined as any code with inadequate test coverage.’ All the time you spend hesitating*** because you’re worried about breaking old crappy code is time you’re not building features or refactoring old crappy code.

10) “Simplicity–the art of maximizing the amount
of work not done–is essential.”

Think Apple. Think Oblivion when they decided to voice all of the dialog, and all the streamlining that inspired/required. Think about that super-expert programmer you know who can tell you why every single line of code they wrote is there, and also why everything not there is not there.

11) “The best architectures, requirements, and designs
emerge from self-organizing teams.”

Ask the people who know the most about something to make the decisions****.

12) “At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly. ”

Continuous improvement. Read ‘The Goal*****’. Really. It will improve your life. Also retrospectives.

*Similar to reading Wikipedia and trying to figure out the actual events behind the dry descriptions…

**I still remember the day when I felt I had ‘graduated to short stories’, as they tend to pack more large ideas per page. Longer novels tend to be more meditative/escapatory?

***And working around crappy code…

****I’m currently most comfortable with some mix of Scrum and Kanban. They have a specific separation of powers between the team (handles estimation) and the product owner (handles prioritization). To me, this seems totally reasonable, but re-reading the manifesto above, there are many levels of Agile actualization above that. (Think Valve.) (Also, the product owner is part of the team, just with a specific role to play in addition to the general team tasks.)

*****https://en.wikipedia.org/wiki/The_Goal_%28novel%29 My favourite business book. Told in a novel format. Some of the story has dated references (before most of feminism), but is still very useful.