Category Archives: Software Development

Sufficiently Complex Systems

“Any sufficiently complex computer system is indistinguishable from a biological system.” -Me

So, I like to joke that I find all computer languages equally difficult[1]. The interesting corollary to this is that this also seems to apply to complex systems in general. I approach a complex computer (or other) systems in the same way that I would approach a biological system:

1) Look at the visible behaviour/symptoms/phenotype of the system[2]
2) Assume that there are some number of internal processes in the system, each doing the job they ‘think’ is correct
3) Build a mental model which describes the visible behaviour
4) If debugging a problem, this should greatly narrow down where you investigate

Steps 2) and 3) above are where I think my school training (engineering and science) were the most useful. Our engineering program seemed to focus on the fundamentals and underlying systems, so that one would have a pretty good idea of what individual system components are capable of[3] (and some idea of what the system as a whole is capable of).

The systems I understood most intuitively[4] were chemical systems, probably because my dad and his dad were both chemical engineers. You have a huge number of molecules[5], each doing its own thing, and in aggregate, they exhibit complex behaviour. When you’re dealing with inorganic compounds, you can (most of the time), simulate them in bulk, but when you’re dealing with organic compounds, the complexity explodes and all kinds of strange boundary effects become important.

At this point, you need to switch abstraction levels, also something I remember from engineering, from the micro- level to a level of slightly or substantially more abstraction. At this point, having an intuition about biological systems becomes much more useful.

I’ll use an example to illustrate. At one point, a number of years ago, I and my team were trying to debug why throughput on a system seemed to be capped at a number below the theoretical maximum. Like any flow system, there must be a number of sequential steps that your data or fluid or what have you must flow through. After we built this mental model, it was a matter of looking at readouts and logs to find the graph that had an asymptotic curve showing at which step the system was maxing out. Then we had to fix it, but that’s another story.

[1]This is probably not strictly true. I remember finding Fortran 77 more difficult than usual, and Javascript mind-bendy.

[2]I use ‘behaviour/symptoms/phenotype’, because we might be debugging a problem, or we could just be trying to better understand the system.

[3]This could be why so much of technological advancement is characterized by the advancement in materials. You can only get so far by using a specific set of building blocks. At some point, you need better blocks.

[4]There is a larger article here about how it’s important to follow the things that love the most, whether this is in hobby form or if you’re lucky, work form. You will work harder at doing them better, more importantly, working harder at understanding yourself and removing your mental blocks, which will help you in all the other parts of your life.

[5]Huge.

Silos and Agile Project/Product Management

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.

<tags and `tags

Note: We went to see Neil deGrasse Tyson speak today, so you get more random musings on tags today!

There are a few previous entries in this series (and maybe more in the future once you read this!). You can find them all using WordPress’ snazzy search function:

http://nayrb.org/~blog/?s=TAGS

So, back to tags:

<tags are showing that your comment was less than something else. Examples:

“I rode a horse” <Clydesdale

or

“I trained my cat today” <successful

>tags are for showing the opposite, namely:

“I rode a horse” >pony

or

“I felt good today” >yesterday

“tags are substituting for the subset of #hashtags denoting quotations, or to substitute for quotation marks in very character starved tweets, such as:

Live long and prosper “Yoda

‘tags are for inner thoughts, sometimes quoting someone else, sometimes yourself[1].

Live long and prosper “Yoda ‘reallySpock

or

Live long and prosper “Yoda ‘neversaidthatdidI

The last one for the day is the infamous `backticktag, invented by people who love programs like the infamous bash fork bomb:

:(){ :|:& };: [2]

`backticktags are used for when you’re meant to take the previous comment and process it through the `backticktag as program code (as opposed to the |pipetag, where you’re supposed to take the previous comment as data)[3].

Examples of `backticktags:

:(){ :|:& };: `bash

or

10 PRINT “LOOK AROUND YOU” 20 GOTO 10 RUN `bbcbasic

[1]For an exciting treatise on this topic, check out this Slate article!

[2]I recommend you do not try running this unless you are your own sysadmin and you know what you’re doing. Indicentally, Wikipedia has a very nice writeup on how this works, copied below:

:(){ :|:& };:
\_/| |||| ||\- ... the function ':', initiating a chain-reaction: each ':' will start    two more.
 | | |||| |\- Definition ends now, to be able to run ...
 | | |||| \- End of function-block
 | | |||\- disown the functions (make them a background process), so that the children    of a parent
 | | |||   will not be killed when the parent gets auto-killed
 | | ||\- ... another copy of the ':'-function, which has to be loaded into memory.
 | | ||   So, ':|:' simply loads two copies of the function, whenever ':' is called
 | | |\- ... and pipe its output to ...
 | | \- Load a copy of the function ':' into memory ...
 | \- Begin of function-definition
 \- Define the function ':' without any parameters '()' as follows:

[3]If you’re playing with a universal turing machine[4] that can intermingle these, all bets are off.

[4]Or Lisp.

TBT: Don’t let your users select invalid options

Things have gotten a bit busy, so here’s a blog post from an old blog that I’m pretty sure very few of you have read, from 2010:

“Don’t let your users select invalid options”

So, in my quest to uncover the roots of all things farming, I went from Zombie Farm, to FarmVille, to the one (as far as I can tell) that started it all (at least in the Facebook era): Farm Town.

There are a few things I’ve learned along the way.

First, mouse motion from a selected and placed object to the square next to it is broken. If you have a 4*4 object that you’re likely to be placing multiples of, once you place one, you should not be able to cursor over the one you just placed. You should immediately have the cursor move next to it, in a legal position.

None of the farming games handles this correctly. It would be interesting to see if SimCity Zoning (if they even still do that) does this correctly between Godzilla attacks.

The closest solution that works is the Farmville tractor plowing option. For some reason, the 2*2 (8*8) plowing square feels much more stable than the 1*1 (4*4). (Each plowed square is 4*4 mini squares.)

Second, the games have been getting better and better with each iteration.

Farmtown, which I just started today forces you to exactly center your cursor on a 4*4 plot (by center, I mean on the correct corner) in order to plant, plow, or do anything with it. Farmville at least gives you a wider hoverable area.

The messages are getting less and less annoying: Farmtown has incessant messages that seem unimportant, Farmville’s messages are even more incessant, but seem more important. On second thought, maybe this is just a graphics upgrade.

The most annoying part of both, though is the “You have…been disconnected from the mainframe” and “…no longer in sync with the server”, which cause very different , but almost equally as annoying bugs. In Farm Town, you have to reconnect every so often, but this seems to have no discernable effect, as your crops look exactly the way that they did when you disconnected… In Farmville, you’ll be halfway through a large harvesting/plowing/replanting, and the ‘server will get out of sync’, and you’ll have to start all over again. I have never figured out why this is not saved correctly on the server, probably they don’t think it’s important enough. It’s gotten to the point that whenever I’m about to do something, I refresh the page, which *certainly* doesn’t save them bandwidth.

Anyways, this has gotten into a lot of minutiae, but the real point here is that when you’re designing a UI, you should not let your users select invalid options. Channel them into what most people do, and is most likely to be what they want to do (make common things easier without making uncommon things harder, as much as possible). The Microsoft endlessly changing menus bother me for reasons like this, because the user experience is not predictable, and doesn’t really channel you towards where you want to go, because the way the menu is portrayed is fragile and could change at any moment.

(Joel on Sofware had a much better description here: http://www.joelonsoftware.com/uibook/fog0000000249.html)

Better Conference Calls

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

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

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

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

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

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.