In Project Management, if one thing is for sure, it’s that nothing is certain. You can try to plan everything to a ‘T’ and account for every possibility, but there will invariably be things that pop up unexpectedly. Sometimes this leads to project managers thinking, “If only I held more planning meetings and spent more time talking things over with my guys, then their best laid plans wouldn’t go awry“. Instead of looking back at the project planning as the issue, we can perhaps learn more by better understanding the nature of uncertainty itself. Uncertainty is a very important topic in quantum physics and understanding the nature of the universe. Since Scrum already uses some physics terminology, like velocities and projected values, I thought it would be fun to run with this idea and take some of the implications of quantum physics and see how they would translate if applied to project management.
Before Breaking Bad brought him back, most of us remembered Werner Heisenberg for his uncertainty principle from high school physics. Mostly that you can you can never fully know the position and momentum of a particle at any given time. This is often misused or confused with the ‘Observer Principle’ meaning that you can’t measure something without actually affecting its outcome. For example if you have an electron traveling in space, the only way that you would be able to detect it would be by having it react with some other particle or detector that would then relay that information back to you.
When we detect the electron to tell us where it is, we have to transfer or absorb some momentum from the electron, thus changing its momentum. It’s like if you have an overbearing manager demanding constant status updates. He or she keeps trying to gather information from their developers are consequently affecting the team’s momentum.
So what does the observer effect have to do with uncertainty? Nothing, really, but it’s often misrepresented as a result from uncertainty, so I thought I would address it first. This principle also has common classical examples, like how you can never accurately take your temperature using a mercury thermometer. Because the heat from your mouth flows into the thermometer and slightly cools your body, you can never get a truly accurate measurement.
Heisenberg’s actual uncertainty principle is represented by the formula:
Δx · Δp ≥ ℏ/2
Where Δx is the uncertainty of position, Δp is uncertainty of the momentum, and ħ is Plank’s constant over 2π. If either of these values were completely knowable, then the right side of the inequality would be 0, rather a constant. The fact that it is a positive number means the more you know about an object’s position, the less you can know about its momentum. Again, the more you are checking up on a team’s progress there comes a point where you’re just affecting their momentum and not learning anything new. But a lesser known relationship is:
ΔE · Δt ≥ ℏ/2
Notice that it has the exact same form as the previous equation. That’s because these are conjugate variables and also have to abide by the limit of uncertainty. Similarly, there is an inverse relationship between the uncertainty of position and momentum, the same relationship exists between energy and time. The more you know about how much work is required for a particular task, the less you know about the time it takes to complete the task.
Many Scrum teams already account for this by using Story Points for estimates rather than using hours. Story Points removes the rigid constraint of estimating work in hours, and instead allows estimates based on similar user stories you’ve done in the past. I’m not saying that one method is better than the other, or would be the best for your team, but you’re not constrained by cosmic forces like uncertainty.
Since Scrum is an iterative process, you can have great success by focusing on things that you can say with a fair degree of confidence, while still allowing for some uncertainty in all planning and estimates.
As you read this headline, many things came to your mind, probably. You might have recalled those many hours of meetings as you tried to come up with a time estimate for a project or for a product release. Or, you might have remembered the planning poker sessions, which were intended as a spot-on pragmatic business activity, but in the long run proved to be nothing else than a child’s game, because the estimates attained as a result of planning poker sessions differed 2 or 3 times from what the actual work really took. The sharp question that I want to ask is: how many times did you feel deep inside that when they make you do an estimate (them being managers, or clients, or anyone else in charge), you end up with nothing else but a waste of time, because later in the project you still face the need to explain why your initial estimate proved to be that different from how things actually turned out, and feeling guilty in the process, though probably nothing of it was actually your fault?
Don’t get me wrong. My initial intent was pure and well-behaved. I humbly wanted to write an article to sum up techniques for estimation used in agile, describe their pros and cons, and provide people with a single-point reference for all those techniques. However, as I went deeper into the research, I was astounded. It turned out that there are many more articles and write-ups out there in orthodox agile circles on “How to estimate?” as opposed to “Why estimate at all?” In those few cases, where I saw some attempts at explaining “why?”, they stroke me as incongruent and built on some very loose logic. This very fact of the looseness of “why?” puts a big question mark on the validity of the “how’s”, because the “how” is a product of “why?” or “what?’ I’ve cited this in one of my previous articles, and I’ll repeat it one more time, because this axiom is universal, and works for all things life and project management alike: The hows will appear if the what becomes clear.
Let’s take the scalpel of pragmatism and dissect the faulty logic behind all things agile estimates.What is an estimate?
Is it a measure of commitment? Or is it a lazy talk? I tried to find some stats on the actual usefulness of the estimates in story points, and how they’ve proven themselves valid in the bottomline world of business. I found none. From my own experience, I know that estimates never work. I’ve seen this in project-by-project software development and in product development. A slightly modified quote from here:
It’s impossible to estimate something that is being built for the first time.
We never build the same feature twice.
The only viable example of valid use of estimates that comes to my mind goes as far back as to the early 2000′s, when people wanted simple e-commerce web-sites, or dating sites, or something of that kind. Having built a handful of such web-sites, software vendors were more likely to give their clients a realistic estimate of completion, because these web-sites didn’t have a heavy baggage of residual debris, such as technical debt, bulky databases, or an octopus-like architecture, which just spreads, rendering futile any attempts to commit to the bottomline “get the sh..t done on time” stuff.
Next, if any attempts at estimating are futile, then why do most companies continue to play this game, which resembles courting, but unlike courting promises no pleasure ahead, only the ever increasing snowball of mess, feeling guilty, unproductive and unaligned with the only goal that matters: get the job done well and on time?
Stay tuned for the answers and even sharper disclosures in the upcoming part 2 of this article.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
So, you want to be an Agile shop. You’ve read all kinds of cool stuff about Sprints, and WIP limits, and daily stand-up meetings. You even think you get this crazy User Story and Planning Poker stuff. You put together a room with snacks and lava lamps. You have all of your stories in a cool ALM tool like VersionOne and displayed on a wide screen TV. So you’re ready to go, right? Well….maybe not. You are missing the most important part….the people. Remember that one of the principles of the Agile Manifesto is to “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” In order to be successful, we need more than just motivated individuals, we need motivated Craftsmen.
Lets start with a disclaimer. I use the term Craftsman in a gender neutral sense. If folks feel like I should change this to Craftspeople, let me know and I will. I get a lot of inspiration from the Software Craftsmanship movement, which tends to use the word Craftsman.
So what is a Craftsman, and what does that have to do with Agile? Agile is hard. It is a very highly disciplined approach to software development. It also is very fast moving. If we expect to be able to “welcome changing requirements, even late in development”, we need to have people with a high degree of skills in order to do that. A craftsman is someone who takes the craft of programming seriously. One who will not do garbage work, and will not accept garbage from her peers. Lets take a look at the values delineated in the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
We’ve all seen these many times, but let’s now look at the Craftsman’s Manifesto. You can find a link here: Manifesto for Software Craftsmanship
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
So really, they are symbiotic. A well performing Agile shop will have Craftsmen as the vital part of their team. A team of Craftsmen, by their very nature, will be embracing those values and principles of the Agile Manifesto. So don’t forget the people as you build your Agile shop. Create an environment that encourages those great practices like Test Driven Development and Continuous Integration. Allow your team members the freedom to practice their craft, and the opportunities to enhance their craft. In the end, you will have your motivated individuals who will delight in getting the job done.
Now that I’ve had a week to reflect and let the experience sink in, I wanted to share my thoughts of our first official Baltimore Lean Coffee event.
I’ve participated in ALN DC events and even helped organize a PMI Agile meetup. So, where did our new event fall on a scale compared to the others? Did I feel like attendees received value and did I feel like we got a good return on our investment? Let me give a little comparison.Lots of effort – Too much process – Formal – Minimum ROI
WDCPMI (Washington DC PMI) Agile meetup is a more formal event that is trying to get its legs. Cost will vary, depending if you’re a PMI member or not. It’s targeted to the Washington DC project manager community. To be a host, you have to ask permission to hold an event and jump through some hoops with the local PMI Chapter. It’s a PMI evening event, so you can’t simply order pizza. It gets catered. You have to make sure you’re compliant with PMI Chapter processes. To me, the process and effort put into organizing and holding the event is not worth the value it delivers.Less effort – Not too much process – Less formal – Good ROI
ALN (Agile Leadership Network) DC is a semi formal event that happens once a month in the evening. For $10, you get an evening of pizza, an opportunity to interact with others, and listen to a guest speaker. I like it because it’s casual and it’s good to see others from the local Agile community. What I don’t like is it’s in Washington DC and it’s in the evening. For those who want to see their families after a long day, this can be an inconvenience. I’ll admit, I am not an organizer for this event. I don’t know how much overhead is involved. (I would love to hear from someone in the comments) The group does a good job of not letting the process get in the way.Minimal effort – Minimal process – Informal – Maximum ROI
Baltimore Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. We don’t charge anything to join us. If you want to grab a cup of coffee (or other beverage) and a pastry, that’s up to you. Our meeting was 07:30-09:00 on a Friday, allowing people who had to go into an office (or even work from home) time to join us. The last voted topic of our meetup was the time and location. In true Agile form, we discussed it, voted, and decided we liked the time and location. Our next meetup is August 8th back at Mad City Coffee.
I've listed a whole series of Kanban Coaching Professional (KCP) Masterclasses for the 2nd half of 2012. These classes are typically residential and can be consumed as 2 x 3-days or in a single 5-day week long intensive class. Typically 4 out of 5 people are choosing the 5-day version of the class since we introduced it at the beginning of 2014. These classes are a big commitment in time and money and we often get asked where the value is? I'd like to explain.
Success has many fathers! Recently, there has been some content published elsewhere on the web that seeks to re-write the history of the adaptation of kanban systems into the field of creative knowledge work. The individuals publishing these alternative versions of history are generally doing it for self-serving reasons or in some cases as deliberate misinformation to try and undermine my business. To put the record straight, I've compiled this definitive history...A History of Kanban for Creative Knowledge Work October 2004
Dragos Dumitriu, manager XIT Sustaining Engineering at Microsoft, asks me to help him. I design a pull system for Dragos' group and coach him on how to introduce it. He "sells' the idea to his bosses and his 4 product managers who act as his customers. The pull system was implemented on Microsoft Product Studio (a forerunner of Team Foundation Server). There was no physical board. The engineering team was offshore in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.
Fred Brooks warned us of these dangers nearly 25 years ago in The Mythical Man-Month.
One antidote to the PM schedule crunching technique of throwing warm bodies at the problem is to remove the impediments that are known (or just under the surface) within the structure and environment that holds the team back from performing at more efficient delivery rates. So many times the line workers (developers and testers) are well aware of these issues, and feel as if they have raised them many times and gotten little attention (mostly negative attention) from managers. A classic game (Innovation Game) to expose these impediments is Speed Boat.
I just saw this image of the anvil holding the balloon down and thought it would make a great visual metaphor for the Speed Boat game. See the article by Alan Dayley Velocity is Like a Helium Balloon to get a hi-res poster.
WARNING: Shameless plug for my session at Agile2014 ahead.
I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.
In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.
Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.
Here are some factors that I think go into figuring this out:
- Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
- Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
- Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
- Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
- Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.
How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.
So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:
Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)
And here’s the formula in action:
Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.
Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.
Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.
In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum.
I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they do agile if they say they do agile.
But saying you do agile doesn’t mean anything if you don’t get to done on small stories and have the ability to change. I hope that if I suggest some small list of potential books, people will read the books, and realize, “I can do this!”
I am probably crazy-optimistic. But that hasn’t stopped me before.
I would like your help. Would you please review my list? Do you have better books? Do you have better suggestions? It’s my list. I might not change my mind. However, if you comment on that page, I would know what you think.
Thank you very much.
Forgive me for bringing up show tunes. I love the old musicals. One of the true classics of American theater is the show Oklahoma. I got to thinking about this in a very roundabout way the other day. The song, called “With Me It’s All or Nothing” got stuck in my head. Let me tell you why…
If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?” These questions are fun to argue about. They are mental candy. But the bottom line is, just like candy, they can also be bad for you. If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development? Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts? I don’t think it does.
The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief that we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work. If you have an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”. I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.
I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal. The real power of Agile software development is not the fact that you do things in smaller increments, or that you write your code test first, but in the supporting power of each of these elements. The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing. Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms. If you didn’t want mushrooms, why did you order the pepperoni and mushroom?
This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development. The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required. After a while I couldn’t help but ask “why are we arguing about this?” The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming. You see, with me it really is All or Nothing.
I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”
When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.
I bet you’ll enjoy it!
We use Slack as a team collaboration tool, and it displays cheering messages on load screens. Such as, “What good shall I do today?” or “You got in, and day just got better”. One such message from Slack inspired me to write this post. The message goes like this: “Remember to get up and stretch once in a while”.
There’s no doubt, that with the bulk of our days spent at our desks, we do need some sort of stretching. It’s hardly that any IT worker, or knowledge worker, will question the need to exercise and to keep fit. Media advertise lifestyles where some sort of physical training is a must. So, if we don’t want to be labelled as “couch potatoes”, or if we lack movement, we naturally want to compensate for that. Many years spent studying, and then working, and sitting all the while, require some sort of compensation. At one point or another, any sedentary worker will want to step on the path of exercising. It seems, what can be wrong about it? Everyone is doing this, and it feels so great to exercise! The devil is in the details, as usual, and I want to outline the trend that I currently observe with some of my colleagues, and which, actually, I observed earlier in my own life. This is not a wellness blog, and this article is not about wellness and keeping fit. It is about keeping ourselves sustainable for doing our work in software development. It might sound as a bummer, but if we put too much of our personal energy into exercising, this will not only be of any good, but it will, in fact, sabotage our productivity.
It’s quite hard nowadays to resist following the lifestyle that media impose. We are told to go jogging, or to ride a bike, or to be a triathlete, or to run a marathon. I’m 100% certain that everyone who will read this article is either doing these activities themselves, or has some friends that do. Now, here’s what the trick is. As I was able to observe, people usually start out with their athletic pursuits after they lack physical movement for many years. It’s as if they are let loose from a leash, and it’s a euphoric experience, to feel yourself moving, exercising, pursuing, being an athlete. Until there comes a time when you realize that this euphoria is not endless, and investing too much effort in exercising backfires, and backfires hard. That was the case with me. In my late 20′s I felt some sort of itching to exercise, and I started out with jogging in a nearby park (on concrete, and jogging on concrete is a knee joints killer, no matter how hype your sports shoes are, but that’s a whole other story). Then, I really got into tennis and passionately devoted myself to mastering this sport. I’m a stubborn and persevering girl, and if you’re serious about doing tennis, you need to keep yourself in good physical shape. So, apart from my tennis practice, several days per week, I did jogging, went to the gym, did some tennis-specific workouts, and I used to have 2 or even 3 training sessions per day (!), and I was doing this in parallel with my day job. Everyone cheered me, because it’s a commonplace belief that it’s such a great thing for knowledge workers to exercise. I managed to maintain this regimen for about 7 years, until at one point of time I realized that I can’t do this anymore. Instead of being a joy, playing tennis — this most beautiful, graceful, smart and elegant sport ever — turned into a dull burdensome chore for me. Besides, my health deteriorated, and this prevented me from doing my best at work. I realized that I need to make a choice, and since I had no intention of becoming a professional athlete, I terminated my tennis practice for an indefinite time. Someone might say, come on, you can just play leisurely, once or twice in a week! The point is that with this fatigue from overexercising that has accumulated over those years, I’m happy and comfortable with this indefinite break. Now I exercise as I swim in lakes (no chlorine for me, thanks), or go on walks, and my favourite way to exercise at the moment is to walk barefoot in a park, on a grass lawn.
Why I’m telling this story? Ironically, I see that some of my colleagues in their late 20′s experience the same curve of being fatally drawn to exercising. They suffer from injuries, but still exercise, as if butterflies drawn to a fire. Everyone lives their own life, and it’s their journey. But I can clearly see, and I can tell from my experience that overdoing with exercises is not only harmful for health. It switches focus from work to exercising. If you have friends who show these symptoms, try to talk them out of the exercising madness, if they agree, and help them look at their life from the perspective of holistic personal energy management. There’s a great book that can help with that. We don’t need the overstrain and depression from exercising ourselves to death. This is not a war, and there’s no way that someone will put up a monument on our grave for that. We need some sort of light activity, and it’s a matter of personal preference. As for me, I’d rather prefer not to expose my spine and joints to unnecessary physical load. Sitting in a chair, no matter how ergonomic it is, is bad for our spines, so I’m particularly sensitive about all things spine, and I’d rather do some soft exercises, such as yoga postures, or stretching (I’ve got the whole baggage of cool tennis stretches from the years of my practice :), or use a fitness ball. Or, walk and swim. Skimming, biking, or, God forbid, jogging on a concrete are my least preferred kinds of physical activities. Another bottomline thing is that the healthcare bills are not ethereal. They are real. So, if we do not want to end up being healthcare bankrupts by our 50′s, it’s better to use caution about exercising as early as in the 20′s, or at least 30′s.
Last week-end I had a flashback to this do-or-die exercise mindset. I was walking barefoot in Delaware Park, enjoying the feel of grass and fresh air after the rain, the landscape was so serene, and there were not too many people in the park. Then, I saw a massive guy, who was obviously doing some sort of plyometric training, running uphill in sprints. He was huffing and puffing, and, as I sat nearby, I could hear some hard-and-push music from his earphones. Well, his huffing and puffing was actually breaking the serenity of the moment, but I could definitely empathize with this guy, because he reminded me of those days when I used to be like that myself. Then, after a while, the guy was done with his training and, as if sensing my discomfort, said to me as he passed by: “Now you can have it all to yourself”. I laughed and said: “I hope your workout was good!” He didn’t answer and looking at him one could say that he was rather exhausted than happy and filled with energy after this workout. Then, I proceeded walking barefoot around the loop of the Hoyt Lake, and spotted a beautiful piece of street art as I went:
Now, tell me, who do you think felt recharged and re-energized on Monday? Me or that guy? The answer looks obvious.
In my role as technical editor for agileconnection.com, I have the opportunity to read many terrific articles. I also have the opportunity to review and comment on those articles.
One such comment is what do teams do? Do they “gel” or do they “jell”?
Gel is what you put in hair. When you “gel” things, you create a thick goo, like concrete. Teams are not a thick goo. Teams are flexible and responsive.
Jell is what you want teams to do. You want them firm, but not set in concrete. When teams jell, they might even jiggle a little. They wave. They adapt. They might even do a little dance, zigging here, zapping there.
You want to keep the people in the teams as much as possible, so you flow work through the teams. But you want the people in the teams to reconsider what they do on a regular basis. That’s called retrospecting. People who have their feet in concrete don’t retrospect. They are stuck. People who are flexible and responsive do.
So, think about whether you have a gelled or a jelled team. Maybe I’m being a nitpicker. I probably am. Our words mean something.
If you have an article you’d like to publish, send it to me. You and I will craft it into something great. Whether or not your team jells.
XP is an approach that helps us to deliver valuable software iteratively, to apply it we need to setup our teams to make releasing change to customers as easy as possible. We avoid waiting around for individual team members to make changes, by applying classic XP practices -- Collective Code Ownership and Pair Programming. Each pair of developers is free to change any code that they need to without anyone vetting their changes, they ensure that all tests pass and keep code relatively clean by refactoring as they go. We share knowledge across the team by rotating pairs daily. If a pair runs into difficult decisions regarding design choices, they can call for a huddle with their team mates, sitting together in an open workspace means that's quick to do. This XP way of developing code is liberating as we can easily make changes in the right place rather than working around organisational barriers. It can be also be humbling, as our code is often improved by other developers as they pass through.
To work this way, we find it helps to build teams of extremely capable developers who can work on any area of the codebase rather than hiring a mix of frontend/backend/DBA specialists. Developers who only know enough to work in a single layer of the codebase limit who's available to pair on the piece of work which is most valuable to pick up next. At Unruly, we only hire “full-stack” developers, this gives us confidence that any pair of developers can work on any area of the codebase (within the products that their team is responsible for) without experiencing hand-offs and delays waiting for developers with a different skill set. It also helps avoid some of the friction that can spark due to single-layer thinking.
Being a full-stack developer is also much more than becoming a polyglot programmer. Laurence Gellert’s explains in his blog that there’s a greater breadth of skills that a “full-stack” developer needs. You’ll need to appreciate the environment that your live system runs within and have the technical chops to be at home with making environment changes. You'll also need to broaden your horizons beyond thinking about code and get to grips with developing a fuller understanding of the business you work in! Michael Feathers recently gave a talk in London where he used the term “Full Spectrum Developer” which neatly captures the idea that there's much more than being able to work across different software layers in a given architecture.
As the software craftsmanship movement has brought to the fore, serious developers need to take personal responsibility for improving their skills. Of course, becoming a full-stack developer is more than reading the odd business book in your spare time and writing toy programs in obscure languages when you get home from a long day at work. You can also get together with likeminded developers on a regular basis to hone your skills through Code & Coffee sessions outside work and work on pet projects like building games and mobile apps at home. But in my opinion, this only scatches the surface - you will only get to grips with being a full-spectrum developer by working in an environment that allows you to get your hands dirty across the full stack and interact directly with users and stakeholders. Typically these are startups or small companies that practice agile software development. If you take a look at our current open roles, you’ll see they’re much broader that you’d typically find in a large corporation.
As an agile coach working with product development teams at Unruly, my focus is on how we can support developers to expand their horizons, to gain a better understanding of our business and how they can help figure out the most valuable software to deliver iteratively. Our developers take responsibility for researching different strands of product development and identify the most valuable ideas to take through to implementation (I'll write-up more about how we do this in another post soon).
We also recognise that build learning time into our work week is essential for developers to stay abreast of new tools and frameworks. All of our developers get one day per week to dabble and learn new technologies — see my previous post about Gold Cards. We recognise that industry conferences can be places where you hear about new trends so developers get three days and an annual allowance to spend on attending any conference they feel is relevant to the personal development at work. Our developers also take turns running weekly coding dojos (during work time not through their lunch) to get hands-on practice time with new languages such as Go, Scala, Rust and mobile phone application development. Developers get the opportunity to share what they learned to other teams through lightning talks and this gives them practice in presenting too. All of these things are ways that organizations can support developers in broadening their horizons while at work rather than eating into their early mornings and evenings.
There are a few things for developers to weigh up when considering whether to specialise deeply or broaden their horizons. What do you sacrifice when following one path versus rewards to be gained? The main reward for full-spectrum developers is building greater confidence to dive into different technologies; you may spend less time writing code but become more able to deliver end-to-end solutions that hit the spot. As generalists, you likely have a wider choice of companies to work at and are more resiliant to industry trends. As specialists, you gain the pleasure of total immersion in a particular sphere of software while you build tolerance to the frustrations of waiting around for others to do their bit. It's up to you!