Category Archives: Software Development

Deadlines are a Clarity Crutch

Agile, Idle Speculation, Organizing Systems, Software Development, Thoughts on Thoughts, Words!, Writing

I have a love/hate relationship with deadlines. At one point I said that the amount of work I do is proportional only to the number of deadlines I have, not proportional to anything else. (I think this is one of the reasons I favour daily 5-minute standups. They allow a daily reset of expectations, along with a deadline to work towards each day.)

So, deadlines proportional to accomplishment. Daily blogging something to show for your year something something etcetera[1]. But today I wanted to talk about the mental clarity that arrives as you’re approaching a deadline.

You have a task/deed to accomplish, you have a fixed time when it is due. As the time gets closer, the light cone[2] of possible ways to solve the problem shrinks. You push aside a large number of extraneous things[3], choose how solved you can get the problem in the time alloted, and get it done.

There’s the standard ‘good, fast, and cheap…pick two’. It feels like a lot of this clarity comes from having chosen the speed. As the time grows shorter, the number of ways you can now spend your mental focus budget on the task becomes manageable.

So, knowing this, how do we compensate? More frequent deadlines do actually seem to help, but that’s more of a forcing a solution, rather than relaxing into a solution.

What is it about the problem that is making you pause? Is your brain working on it in the background? (Does this mean the fallow time is necessary?) Are there parts you can hive off? Can you draw a large diagram? Can you put it in a spreadsheet or table?

Or perhaps the elephant in the room: If it is so difficult to find mental focus, what do you need to change about your environment?

[1]Until writing this I didn’t know that the ampersand ‘&’ was a ligature of ‘et’, and ‘etcetera’ was often written ‘&c.’

[2]Light Cones are also fascinating. I use them often in my mental model.

[3]In undergrad, we used to say that we enjoyed exam time, because we could push everything else away and focus, and not face opprobrium.

Five Management Roles

Agile, Analysis, Organizing Systems, Software Development

I was talking with my best friend earlier today, and we were comparing notes on some different management roles. Traditional hierarchical management theory[1] tends to have all of the management roles embodied in one person. This can be problematic, as very few people are good at all of the management roles.

This has led to a number of different techniques for dividing these roles among people. To start, we’ll talk about five of these roles, using Agile software development language, as that’s what I’m most familiar with:

Performance Manager (Worker Evaluation):

The ‘Performance Manager’ is probably the most traditional of the roles. When someone talks about their ‘boss’, it is generally the person who evaluates their performance, gives them performance reviews, and decides if they should get a bonus, a raise, or be fired[2].

Estimatrix (Estimator):

The ‘Estimatrix[3]’ is in charge of estimating the amount of effort required to perform a task or set of tasks. This role is often spread out over multiple people, even in traditional hierarchies.

Product Owner (Prioritization):

The ‘Product Owner’ is the other half of ‘traditional’ management. They are in charge of prioritization of the work being done, once it has been assigned to a team and estimated.

Scrum Master (Removing Obstacles):

The ‘Scrum Master’ (my favourite) is charged with removing obstacles. Once the team knows what it is working on, things will get in the way. Some of the obstacles are acute issues, associated with work being done, some of the obstacles are chronic issues, which are generally solved by trying to change habits, and many ‘restrospectives’.

(People) Development Manager (Development Conversations):

As a retention technique (and because it’s the right thing to do), many organizations spend time on development of their employees, helping them figure out what they want to do with their careers, and helping to find them ways to develop while doing their job.

Tomorrow, we’ll look at some ways these roles are remixed.

[1]It’s really more of a default.

[2]Like user stories, anytime your description includes the word ‘and’ or ‘or’, it means you can subdivide it further. That is left as an exercise to the reader, if they are so inclined.

[3]I really enjoy this suffix.

Sufficiently Complex Systems

Analysis, Engineering, Organizing Systems, Science!, Software Development

“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

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.

<tags and `tags

Internet Culture, Software Development

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

Software Development

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

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.