On my last project, I managed a team developing an application to manage hospitality locations. Given our requirements were constantly in flux, the contracts were on a short cycle, and the team was generally new to enterprise software development, I chose a Kanban style approach to managing and delivering it. I wanted to share with you the rationale, methodology, challenges, and the surprising change to my role while on the project.

Why Kanban vs Scrum?

Scrum has too many meetings, requires a well groomed backlog, and assumes senior developers so that they can accurately task & plan their stories.

Junior to Mid-Level Team

Given I was running my mid-level team in an Enterprise setting, I knew others would be more than happy to sabotage our teams productivity with meetings of their own. Part of the solution, not part of the problem. New team members, both onshore and offshore, who I expected to be reasonably cross functional whether they liked it or not, needed all the time they could to focus and learn quickly.

No Solid Requirements

Given staffing was changing bi-weekly with an my on-going effort to teach the Subject Matter Experts (SME’s) turned Business Analysts (BA’s) how to create properly groomed stories, there wasn’t anything the team could commit to within a reasonable timeframe. For example, it took us 8 workshops over 3 weeks to get to a solid understanding of what we thought we were building.

No CICD

We also had no build nor DevOps in place to facilitate Continuous Integration and Continuous Delivery. Thus we had no ability for weeks to deliver a working, high quality feature because there was no build to allow Developers & Quality Assurance to verify quality, nor server to deploy it to.

No Roles, Just Fullstack / Cross Functional

Having a Product Owner assumes you have someone either in Business, or who represents them, that knows what to build. The client asked us to use our expertise to help them out in true Consulting style. Thus there was no Product Owner.

There was no need for a Scrum Master. Sprint Planning was pointless because we couldn’t plan 1 to 2 weeks in advanced since high level Epic’s were still being both defined, priced, and architecturally validated. For months. I already knew what the team was working on, and so did they, by their small Trello cards. If people had blockers, they asked me or the team over Slack and we collectively resolved it. There was no need for Retrospectives because there were no Sprints since things changed daily so you couldn’t effectively reflect on what happened the past week because it was ever changing. There were no roles beyond everyone coding the client, server, and some of the DevOps together.

Scrum would of been lot of ceremony with no value.

Enter Kanban

What Kanban does well is allow you to change quickly, allow the team to be productive despite the chaos, with a continuous flow of delivering working software that’s in sharp contrast to the insanity outside their productive world. Unlike Scrum, you much more quickly visualize the work going on “today” and identify problems sooner than later. Since the work in progress tends to be smaller, you can flush out bottlenecks in the process sooner. You can create swimlanes and also identify which ones have bottlenecks.

Flexible to Ever Changing Direction

As each new day brought in new or modified requirements, role changes, and improved DevOps and API offerings, I would change the Backlog to match “today”. Given we had no build, nor DevOps starting from scratch, I had a lot of flexibility to inject more build specific tasks so as to keep away from Yagni until we got a solid enough user story. “No user stories, nor API? No problem, get Mocha working with our Node code.” I’d attempt to stay 1 to 4 days ahead of my team. This was to ensure they were working on what I knew at the time to be real and providing client & user value.

Productive Despite Chaos

Politically, it helped ensure we were being productive and thus visually showing we’re using the client’s money effectively with the fast ability to change course if they wanted something changed faster than a Scrum Sprint would typically allow. This happened often.

Learning the Team’s Strengths, Weaknesses, and Desires

I had a new, junior to mid-level Development team and QA team, on a greenfield client (meaning no existing infrastructure or code), with ever changing requirements, staffing, and contract lengths. Since the team was new and learning the entire Software Development Lifecycle whilst me doing my best to shield them from politics, lack of a CICD process, lack of requirements, and nothing pre-built for them via Yeoman generators / starter projects… I knew things would be slow and unpredictable at first.

What I didn’t know was the team. I didn’t know their strengths, weaknesses, and most importantly, desires. Happy developers are productive developers. A lot of people say they are fullstack to ensure they are employable or because they are insecure that their speciality skill set cannot stand on it’s own. That or they like working in smaller, more cross functional groups.

As much as I expected the team to touch all parts of the development stack, including myself, you always have people who naturally gravitate somewhere, or like to be pushed to a particular area like API’s, services, components, or build level tasks. This should be encouraged just as much as being cross functional to get the most out of them, and the team. Additionally, as the project matures, you have less of a need to be cross functional as often, and tend to see people dive deep over time.

Creating Tasks in Trello

I also didn’t know the team’s ability to estimate their own tasks. It didn’t matter since the user stories weren’t defined enough for them to do so. Thus, I broke all tasks down for the team and included additional DevOps and QA tasks as well into small units. We used Trello, a real-time collaborative project board full of cards, to keep track of the work.

We had 6 columns in our Trello board, from left to right:

1. Bulletin Board: All the documents & images for our project
2. Undefined: Stories & Tasks I didn’t have enough clarity on for the team to work on.
3. Defined: Tasks I fleshed out enough to ensure anyone on the team could work on with clearly defined success criteria, easily merged into a Github Pull Request, and colored with the swimlane it belonged to: Testing, Client UI, Node API, DevOps, and UX.
4. Working On It: What tasks were being actively worked on in the team. I ensured only 1 card per developer
5. Done: For tasks that were done and developer tested, but not QA approved via them manually testing the Card’s associated PR.
6. Approved: QA approved PR’s that merged into the dev branch and deployed via Jenkins Docker build.

Observe the Flow of Development…

What happened next sold me on one of the key strengths of Kanban.

Every day I could immediately see problems. Instantly. It happened just like Andrea Ross said it would, and I’d see where bottlenecks were in the process. Each column in Trello would suddenly get overflowed with cards. You could be near blind, simply squint at the board so you couldn’t actually read anything and STILL SEE IT. The size of the columns told all: you have a bottleneck somewhere here.

It’s called Cycle Time: how long a piece of work goes from left to right. You want to ensure once cards are created, they speed from Undefined to Accepted (left to right, start to finish) as quickly as possible. Typically that process isn’t linear; SOMEWHERE in the journey there is always a bottleneck.

… Adjust as Necessary

How do I know I’m done?

The first one was the success criteria I gave wasn’t clear enough. 90% of my created cards in Defined were moved back to Undefined by the team. Once I gave better success criteria, the development team started to chew through them. I wouldn’t hear from them for hours, then cards would suddenly start piling up in the Done column w/PR’s to boot.

What does the UI look like?

The second one was lack of good wireframes and designs to illustrate both the layout and interactions of how the UI worked. We didn’t yet have budget for a UX resource, so I spent the time myself building low fidelity wireframes that were as accurate as possible and then creating design comps matching our Material Design style guide. I ensured all new cards had relevant design artifacts attached. If the wireframe/design comp changed, I’d move the card from Defined back to Undefined to ensure the team didn’t touch it. If it was too late, I’d create an iteration card to modify an existing piece of work with the updated UI/functionality change.

How do I test it works?

The third one was the inability for QA to test functionality as cards started piling up in the Done column. QA didn’t yet have the build running locally, nor a QA environment to test on, nor a set of tools to help them automate it, nor a lead to help mentor them towards this.

So I picked up the torch, implemented Angular’s Protractor with the Cucumber version, then had a team member get an actual working feature through Gulp. I then worked with the QA team and BA’s to help define better Cucumber features through workshops so they were easier to test. I attached these as additional artifacts to each card where applicable.

Finally, we started Dockerizing our build to use through Kitematic & DockerHub. Given how hard it was to get Redis + Node working the same between the Developer’s Macs and the QA’s Windows machines with various lack of admin rights, this helped ensure things actually worked, quickly, without debugging install or configuration issues.

Continually Improve

This process never stopped. Sometimes it was small bottlenecks or even just blockers and we’d do our best to improve the process. Despite the politics, climate of unknowing, and constant readjustment of requirements & processes… it felt good to be making both progress and improving the process.

Developers got to zone out by donning headphones to jam on code all day. Working code continually emerged as long as I fed this process.

We almost got to the point where the developers had no clue about the ever changing conditions on the ground with the client, ignored it when I brought it up, and focused strictly on questions about specific tasks. I’d call that a process win.

Challenges

It wasn’t all rose colored glasses.

The Importance of Good, Upfront DevOps

The main pain point throughout the entire process was our DevOps starting late in the cycle. Without a good CICD process, Scrum and Kanban don’t really seem to work all that well in tracking “actual work” because no actual work… works. Now, the CI portion we knocked out of the park ourselves and quickly while waiting for confirmed requirements using Github and Jenkins in Docker + AWS. Mostly. The CD, however, took awhile.

What we wanted at first was once a PR was approved, the code would, after a successful Jenkins build, deploy a Docker container of our code to a publicly accessible Amazon Web Service (AWS) instance. It took us about 3 months to get that going given our resource constraints & timing. In the interim, we did a lot of mocks and testing on localhost with ngrok for demos.

Once our Docker deployment was working we started having code be deployed without our knowledge in a good way; the development team just focused on completing cards, and eventually the QA would focus on verifying manually what made it through the automated QA process to the server matched up.

The latter took forever simply because I was stretched too thin running the Development team, helping the DevOps team, doing my own wireframes and design comps, mentoring the BA’s to write awesome user stories via Behavioral Driven Development to minimize our story grooming sessions, and keeping Senior Management in the loop.

Even with Analysts starting the DevOps, it’s clear having them full time on that endeavor payed off big time. In the future, I’m curious if I’d rather focus on that full time myself since it seems to have the largest, cross team impact regardless of whether the requirements, UX, and CI are in a good or bad spot.

Wireframing & Designing at the Same Time vs. Staggered

While me being the same person to do the wireframes made it easier to build design comps around them, it simnifically reduced the time I could spend with other teams. When the Undefined column would get too full, I’d have to spend the early part of the week ensuring I had enough information to wireframe. I’d then spend the weekend on the design comps and then break them down into easily tackled, small PR tasks in Trello. This wasn’t sustainable and I knew it, but was banking on getting budget for UX resources.

While I was helping the BA’s, Development Team, and QA by ensuring the stories had a visual component to help ensure we’re all on the same page of what the user story looked like, I’d end up neglecting other things like refining those very stories, not unblocking the development team when they’d get stuck on build or architecture issues, nor helping push the DevOps team to help the QA do their job.

Rather than complain, I made a daily tactical call on what to focus on based on what Trello was telling me. Once we got the UX resource onboard, he worked aside the BA’s and that helped a ton; at that point I could just match the design comps to his wireframes, cutting my work in half + his were of insanely higher quality for talent & focus reasons.

What this tells me is that unless I have a huge backlog of build and DevOps work in the pipeline, I’ll be hard pressed in the future to keep my development team busy with those tasks for a long time without quickly needing a proper UX team member(s).

QA in Lean Engineering

I didn’t have enough seniors to delegate management tasks to, and coupled with my CD problems, I struggled to keep QA productive. While our developers were using linting compilers, complexity metrics, unit and integration testing with end to end testing, no one was laser focused on improving the latter part of the QA CD pipeline. I’d made some headway in getting QA involved in the beginning to help contribute to ensuring good user stories came out of our workshops. Where I struggled was giving them enough of my time to teach them basic JavaScript coding, DevOps, and helping them walk through their testing plans on what we did have to start to develop a cadence.

A lot of this was we just didn’t have that much to test yet and the other was… well, nothing. I did the best I could working insane hours. If I were to do it again, I’d assign a senior dev interested in furthering their testing & DevOps chops to work with them on owning the CD process, and ensuring a good quality pipeline.

In Lean Engineering, QA is no longer thrown code to test weeks or months later. Instead, they are brought into the beginning of the process and the end to improve the entire pipeline. You can’t do that if you don’t have a DevOps pipeline.

User Feedback

The same problem I had with QA I had with user feedback. Part of Lean engineering with Kanban is continuously improve not just the process, but the software. You do this by giving the working build to a user, testing it, and taking their feedback BACK into the process. While doing wireframes, I did informal and adhoc user interviews, created basic Persona’s to differentiate who we were targeting, but did not get to validate this with released software until late in the cycle.

This actually wasn’t much of a bad thing, but rather, a challenge because a working build didn’t emerge until much later in the cycle, so we just did localhost demo’s & testing vs. “use whatever device you have on your person or will use in your job”. I had already had extensive, informal discussions with the target users and really liked them as people. It just came up when I’d look at swimlanes via colors in Trello cards, the features had a huge cycle time in knowing if they were valid or not from user testing.

Role Changes

Traditionally in Agile, I’ve found I do most of my management efforts on Sprint Planning and post Retrospective. I ensure the requirements are rock solid and follow up on loose ends, and take action items seriously during retrospectives where new things need to be implemented or changed. The rest of the time I architect, pair program, and code.

In Kanban, it was very different. My role, daily, was to manage away problems for the team. Instead of a weekly or bi-weekly discovery, this was daily to hourly. I’d adjust based on what Trello was telling me. It gave me a greater insight into how my management efforts positively and negatively affected the team.

I also liked continually working with the team to improve our process. I’ve done that before in teams with Scrum, but process improvement usually fell behind “getting my story done” in terms of priority. In Kanban, fixing the bottleneck and improving the process is the priority.

I’ve found I really like Kanban. The consulting world is full of extremely hard software problems surrounded by politics and chaos. I love those aspects and Kanban is now my tool of choice for managing teams within it.

Citations

I wanted to thank Joel Hooks for telling me about Kanban being an alternative to Scrum years ago. If Joel likes something, I typically trust his judgement that it must be good.

Also thanks to my manager, Matt Lancaster, for teaching me about Lean engineering processes. You can see him speak about the process below.

Thanks to Eric Motazedi for teaching me about BDD and why workshops are so important.

Finally thanks to the Richmond Capital Kanban group for teaching me more about how Kanban works.

IT Wastes

Andrea Ross did a presentation about waste in IT. Kanban, the production process used by Toyota then turned into a Project Management and Software Development, has 7 or 8 forms of what it calls waste. These are primarely in the factory line production process, so you have to draw your own metaphors and similes, and that’s what Andrea’s presentation extrapolated on.

From a high level, these are:

• Defects / Rework
• Overproduction
• Waiting
• Non-Standard Over Processing
• Transportation / Logistics
• Intellect
• Motion
• Excess Inventory

Her slides that have bullet point examples for each one are pretty self-explanatory. What was interesting to me was the sheer volume of bullet points I see all the time, together, in the same projects I work on. Some can’t be avoided, nature of the business and all that. Still, it was pretty eye opening to see that a traditional Factory Production process has identified these items as the core waste items, and software development has plenty of them with just about the same meanings. I won’t cover them in detail here as her slides do.

Kanban, Bottlenecks, and Waste

The concept of Kanban is to quickly identify bottlenecks in the existing production process, and iterate to improve the process to fix them.

Notice I said “existing” and “process”. The existing part is where Kanban has been easier to market than say Six Sigma which is bought into wholesale, hence why it’s easier to be a Six Sigma consultant than a Kanban one. Kanban you basically overlay on top of what you have and it surfaces the problems your existing process has pretty clearly. Meaning, if you see a bunch of cards on a Kanban board that are in the “Analysis” column, and very few in the rest, it’s pretty clear where the bottle neck is located.

Now the “process” part is analogous to the production line; in this case all that goes into making software from the traditional waterfall perspective: design, development, deployment. However, the key here is you aren’t fixing the “bottleneck”, but rather the process itself. That is what I learned through our Paper Airplane Factory exercise quite clearly. There are a series of games like this that can be modified, but the point is they help teach the bottleneck vs. process modification process extremely clearly.

The key takeaway for me was fixing the bottleneck, like the 5 developers + 1 manager in a war room during a troubling moment during a software project, is actually a form of waste. Yes, it’s great teams rise up to tackle these problems in the moment. However, it’s important to note that it’s the Project Manager’s job to both recognize this as waste and fix the actual process problem. I’ll explain this below.

Note: If you’re concerned about spoilers, please be aware of 2 things. First, there are more than just the airplane factory game that you can find online. Second, if you do read the following section and later participate in the exercise, please either let the teacher/presenter know, or try not to modify the process too much to allow others to learn.

Airplane Factory

The game is like so (abridged version, you can find the full instructions here):

1. Divide your people into 4 groups, each sitting adjacent to each other. Circle or semi-circular seating arrangements works best to encourage intentional bottleneck adjustment engagement.
2. Cut up the airplane folding instructions alone the designated lines.
3. Give the first part of the instructions to the first group in the line. Give the second part of the instructions to the second group, and repeat on down the line. Some people may not necessarily have designated jobs beyond passing papers, etc. This is intentional to illustrate the intellect waste of not using human IP… and also to note how they’ll often become efficient passers, helpers, or even QA.
4. Ensure the group/person who’s last in line is aware of how far the plane must fly as a metric of defining a successful plane.
5. Setup a 5 minute timer, start it, and yell “Go!”
6. After 5 minutes, identify how many successfully flown airplanes were made as well as how much waste (crumpled papers, non-flying planes, etc) were created. That’s the round 1 score.
7. Iterate.

The iterate step is where you reflect on what just happened and attempt to modify the process. I’ll go over how ours went down so you get an idea.

Round 1

Line Setup: We had 8 people in our line. Round 1, we had 1 lady do the half fold, the 2nd guy do the additional 2 folds + paper sides cut, Andrea and I pass the paper to our left, another lady handle the 1st wing folds, and a gentleman at the end to make the wings and throw it. Our last person was a lady who handled QA and scoring.

Process: Very quickly we had a bottleneck with the lady at my stations left. The instructions weren’t very clear and she struggled to learn how to do the first one. Both Andrea and I quickly went to help; Andrea attempting to do it with her, me taking a picture of the instructions with my iPhone, and attempting to duplicate at my desk while ensuring I kept passing the planes to my left into an ever growing pile.

Once I figured it out (I had actually built the exact same plane last week for my daughters birthday present which has an electronic propeller you attach), I told the ladies to ignore the “requirements” as they were crap and I walked them through how to successfully complete their step. I then quickly returned to my desk which had a pile of unmoved inventory.

The only person who didn’t struggle with their assembly was the 1st in the line who had to fold paper in half.

I believe we ended up with 2 planes and 1 waste.

Takeaway: Our teacher quickly pointed how we went “downstream” to fix the production line process. This is a reactionary, and completely normal mode, to fix production line problems. It’s also wrong. You’re supposed to identify the upstream problem causing it and fix that. Additionally, we didn’t stop the line to ensure we fixed this problem first before continuing, also wrong. Car companies like Toyota do this via a chain that’s pulled to stop the line so they can ensure the problem is resolved. Sometimes they even take part of their line off the main line to ensure things keep moving.

As a side note, apparently GM used to keep going. Door doesn’t fit right? Keep going; jam the mofo on there. They’d end up with a lot full of cars pretty quickly… even if they were low quality. Ford was similar, but they’d ensure the cars were actually sold first before they sold them, thus not resulting in lots full of inventory they couldn’t sell like GM… even if the quality of pre-sold cars was still low.

We also noted various other problems such as no training in each plane’s building instructions, no one stopping if the station after them go overwhelmed with their ever growing stack, and sometimes idle resources (people with not much to do).

Round 2

Improvements: First, the teacher actually implemented designated stack areas with a piece of paper on each station, and then wrote a number on the paper; this was the max amount of completed planes you could place for the next station to build so you didn’t exacerbate a bottleneck.

Second, I become a designated passer to my left while my partner moved to the left station to have a 2 women team doing the complicated folding.

Process: My job was pretty easy; pass, and ensure I don’t bottleneck it. Every single station was faster since they had practiced their portion. The guy to my right had actually done his first 3 paper cuts wrong in round 1 which caused confusion to my left station, but had it down pat in round 2. The last station still experimented with various angles of folding to see how far the plane could actually fly. We actually had the last women in the line, QA, send a messed up plane back through the line as an unfolded piece of paper because it didn’t fly right; w00t, less waste!

A bottleneck, again, formed to my left, but the girls found a way to divide up the 2 step process between them to be more efficient. As our 5 minutes progressed, they got faster and eventually started making progress on the backlog.

We made 5 planes, 1 waste.

Takeaway: We built 4 planes with 1 waste. The first person, as usual, was too fast. The guy to my right had an inefficient process because he’d have to fold, pick up the scissors, cut, then put ’em down again. We had all abandoned our airplane instructions by this point.

Round 3

Improvements: Everything else was fine, so we decided to give me the cutting job and the guy to my right would just fold. The girls to my left on-the-fly modification was good and we kept it.

Process: My first 3 were slow, but once I practiced, I was uber fast and we were humming. The girls to my left were killing it. I managed to keep my right stack always below or at 2 in the pile. Very quickly it became apparent the 1st person was too fast; she was constantly folding and then waiting before she was allowed to make another.

We made 8 airplanes, no waste.

Takeaway: Those of with spouses were already getting texted like mad to leave, but we all WANTED to see Round 3 succeed better than 2, and see if we made the process perfect. We didn’t; it went the complete opposite direction to the front of the line needing minor modifications. Overall, though, our output increased a lot, our waste went down, and it was very clear that the adjustments we made + the teachers maximum stack amounts were working well.

My Overall Takeaways

I went to this meeting to both meet new people in town to network with as well as to get out of my comfort zone. I find when I do the latter, I learn a lot and sometimes get a new perspective. It gave me a new appreciation for Project Managers who have not just 1, but 5 projects they have to manage to make an attempt to do this on. This also assumes they get enough time to really learn about each teams issues, where those bottlenecks are, and what the best ways are to address them. NOT by just fixing the bottlenecks, but by fixing the process itself, ensuring stop guards are in place not as many items/cards in a column, etc.

It also made me intimately aware of how I, as a consultant, immediately want to fix the bottleneck, and have learned ways (such as the war room) to solve them… when in reality, it’s a PM issue for a greater process problem. The other thing that makes it more complex is the whole “all things being equal”. For example, a Kanban board a PM would use on the whole process vs. just the Kanban board my software team would use. If my team fails to do TDD and ends up with a variety of bugs in the system because we’re forced to develop quickly and produce bad work, this show up on hers as us being the bottleneck. Without time to talk to us and really empower us to change our process, nothing will change.

I see this time and time again. The excuses, which are sometimes valid, range from “the software’s good enough even with the bugs”, or “TDD is too much work for not enough value” or “we can’t write a test suite for a huge mess that isn’t even testable”. …and that’s just a small portion of what I’ve seen gone wrong. If you’ve ever worked for a design agency, or even a large firm that has a huge new client, it’s very apparent many teams have a hard time getting sign off from clients which causes a bottleneck in the analysis column on the Kanban board because the items either pile up, or priority constantly shifts… yet they never actually make it out of their column.

A PM there who works with the government offered his strategies for dealing with the strange QA cycles government agencies will have where it goes into a black hole for 6 weeks thus really screwing up his Kanban metrics.

Overall, it was neat to be in a room with people who were geeking out on improving process. You see a lot of software developers get bored with programming or frustrated with how their lack of process is going, so they read up on XP and Agile. When you look at what these PM’s deal with, it makes you feel like just a small part in a larger overall process.

More importantly, my preconceptions about leadership being the problem 99% of my problem projects really had a wrench thrown in. I was bitching about it to one of the PM’s, and quickly explained, in great detail, why some big companies which don’t have a hard line metric such as money to predict performance will often use Lean methodologies since “ensuring customer satisfaction” is hard to measure depending on your business, and requires a more exploratory way of doing business. That said, it was great to hear that the common problems I experience in software dev with solutions were the same, just 1 of many that PM’s have to deal with.

I highly encourage software developers to partake in one of these exercises, even if you do Scrum vs. Kanban. Really eye opening stuff.

What is Consulting?

Consulting in the Flash/Flex world usually consists of 3 tasks that may be related:

1. Offer your architecture expertise.
2. Offer your code mechanic expertise.
3. Augment an existing team.

For #1, companies either want you to architect a project, give professional feedback on a suggested/signed off architecture done by another firm (usually to give a stakeholder corroborated evidence), or are having scalability problems and want your advice.

For #2, things aren’t going well and they want you to fix it. No, not re-write it, fix it.

For #3, they want you to augment an existing team. Some firms do this because the pay + finder fee is good money. Other firms do not because you can sometimes be put into situations where you’re setup to fail since you may be smart enough to fix it, but you’re not in charge, thus you cannot do so.

#3 is how I got into consulting, staff augmenting an existing team. While the #1’s were fun, they were few and far between; usually big companies would rather pay lots of money to fix things vs. pay what it costs to do it right. This isn’t cynical, this is fact.

Why Get Into Consulting?

The reason is often simple: more money. More money than full-time/salaried/W2 work. More money than freelance/contracting.

Other reasons include working with really smart developers, learning about how Enterprise companies build & sell software,  learning about how to work in and manage large software teams… TONS of opportunities to just learn on a variety of subjects. Sometimes people havenâ€t worked on extremely large codebaseses. Itâ€s fun to take all the theory and see what it actually does in the real world, with real people.

Me personally, I like travelling, meeting new people, and seeing how different companies work.

Getting Into Consulting

You have a few options listed in order of ease.

1. Find a firm, become an employee.
2. Find a firm, become a sub-contractor.
3. Become an independent contractor.

If you find an existing firm, especially when your country isnâ€t in a recession, this is the easiest way. Whether large like Deloitte and Accenture, to smaller firms (more focused on Flash/Flex) like Roundarch and Universal Mind. Regardless of skill level, while youâ€ll be sold to the client as a “consultant”, but larger firms will ensure a senior is on the project unless youâ€re merely staff augmentation. Joining as an employee usually is easier because youâ€re cheaper tax wise/cost wise to the firm, and youâ€re more versatile to them. Meaning, since youâ€re on payroll, they can pay the same rate to fix a huge clientâ€s code base as well as working on your firms intranet when in between clients.

If youâ€re the freelance type, or typically like getting a variety of clients (and often potentially making more money), becoming a sub-contractor is another option. This is how smaller firms get off the ground, and is common place even in larger firms. While you usually cannot do mundane work, this is often easier for smaller firms tax wise, thus itâ€s an option as well. If the firm has no current clients, you wonâ€t get any work though. A W2 will get paid for the 2 week downtime, you wonâ€t. Hustling during consulting engagements is usually harder than hustling during contracting ones.

If you have enough contacts or typically do only Enterprise type software (LiveCycle, BlazeDS, Java/Spring/Hibernate), then going the independent route is also an option. Basically, start your own company, and start working directly with clients. This is the hardest, even if you do Enterprise software, because most larger clients only work with “companies”. Just because you have a company legally filed on paper doesnâ€t mean youâ€re a “company”. Often theyâ€ll want multiple developers on a whim, liability insurance, and multiple large clients on your track record/portfolio. Iâ€m personally still learning the sales for this, but it seems networking tends to help a lot/the most.

My advice, seek out people you know from the community at Roundarch, Universal Mind, or Cynergy, and make sure youâ€re known to be available, even if they donâ€t currently have any openings.

Skills

Being a consultant involves a lot of things a normal software developer doesn’t do. Even if you’re a salaried/W2 employee, these are still required:

1. leadership
2. large scale architecture
3. travel on-site to client’s location
4. expense reporting
5. meeting clients and their stakeholders
6. offering professional, 3rd party opinions
7. dressing nice
8. attending meetings for a company you don’t work for
9. interviewing/hiring members for your team and/or the company’s on the company’s behalf

All the standard stuff like team management, working with the company’s stakeholders, and tracking your hours are there too. You also donâ€t always do all the above mentioned; sometimes just one. Itâ€s just those arenâ€t normal required in traditional freelancing (excluding #3 and #5). Let’s break down what these skills mean.

Leadership

Unless your role is for staff augmentation, leadership is the most important skill for a consultant. You need to be able to inspire confidence in strangers you’ve just met, inspire confidence in your chosen direction & decisions, and to keep people moving on the right path.

Some leadership skills can be taught. Some people are just born with the other aspects. If you don’t know how to do this, watch & learn from those that do. Examples include raising your Charisma score. Doing one or more of the following will help:

• have good hygiene
• have clean clothes that are ironed
• dress to impress; this boosts your confidence as well. You want to look successful.
• listen: people like good listeners
• empathy: people like others who understand them. If you listen to their pains, and sound like you understand, you connect.
• be knowledgeable: if you know what you’re talking about, you’ll exude confidence when you talk. You also won’t get offended if someone disagrees and will want to hear their point of view. If you don’t know, ask/listen vs. act like you know.
• have a vision: assuming you know the companies problems, have a long term vision to fix everything. Communicating this to your colleague and your clientâ€s employeeâ€s is paramount.
• communication: you need to be an effective communicator to articulate your vision to others, and get them to follow you. Be relaxed, look people in the eyes, be confident in your delivery, and be open to listen. Using slang/ebonics/l33t in normal conversation negatively affects peopleâ€s perception of you. Be professional when you speak.
• egg shells: crush those sons of bitches. You do NOT walk on egg shells. You’re a consultant; grab drama by the neck, raise it high, and execute it. Then, move forward.
• be positive: while Andrew Dice Clay and Rush Limbaugh have gotten popular for their negative spin on things, they don’t last. Positivity is the antithesis to Entropy; that lasts, especially in people’s perception of you.
• control your emotions: software is hard. People in large groups do really dumb things, particularly large companies. Have patience, breathe, and keep your emotions in check.  Your self-control inspires confidence in your actions by others. People assume you have things under control if you’re relaxed and poised.
• win: You have to WANT to win. You need ambition to reach your goals and vision. If you have that, you’ll have the motivation to do all of the above.

Large Scale Architecture

The most common need in the Flex world is architecting how the Flex talks to the BlazeDS/LiveCycle, and how that talks to the Java, and how that talks to the client’s stuff. Often, they’ll have an existing infrastructure in place and you’ll need to decide & describe how and where to integrate technology stacks to a client’s existing infrastructure and possibly already in progress project with the existing resources, which are often in a variety of teams.

You need to know this well enough that you can cater design, development, and deployment techniques to various client needs. You need to be able to effectively articulate these to the client, the team, and ensure the tasks meet the resources currently available; meaning the client can build, deploy, and support what you’re actually suggesting to do. Thatâ€s a lot of traditionally Project Management tasks.

If you don’t know how to architect large Enterprise sized projects, specifically Flex, learn. If the back-end/middle tier isn’t your thing, partner with those who know it. Unlike learning traditional software skills, you can’t really get away with practicing as a consultant. Based on my consulting gigs people can do this all the time if they’re a salaried employee of a large company. So, if you want to get on the fast track to learn, join a consulting firm and get mentored.

Travel On-site to Client

Unless it’s staff aug, most consulting involves travelling on-site to the client’s location(s) to meet the stakeholders and team. This means donning your business casual, booking airfare & hotel, and travelling both on the weekend and during the week. Being responsible by ensuring you have ample lay over time, donâ€t get the last flight out,  arriving to the airport early, and arriving at a client site early to ensure you’ve gotten enough sleep are assumed.

For those with needy significant others and/or young children, this is challenging to do, and will determine if you do higher level consulting or not. This has forcibly paused my career which Iâ€ll defer to a later blog post.

To me, this was one of the draws I have to consulting. I like traveling to new places, meeting new people, and the lifestyle of being on the move. Being on the road is one thing that’s therapeutic to me.

If you don’t have a few thousand in the bank to cover the costs (flight, hotel, fuel, food), the firm you work for will have to front the money. Either way, you have to ensure this is tracked as reimbursed expenses for tax purposes (unless you’re salaried with the firm). The benefit of paying for these things yourself are tax write off opportunities as well as frequent flyer miles with certain airlines.

If you can use expedia.com, drive a car, and find your way around an airport, you’ll be fine. Sometimes you get to meet new people you sit next to on the plane. Yes, there are cool people in coach, but you want to strive to be in first class even if the company will only fund coach. Make sure you use your own miles program vs. the companies if you can. You aren’t paid for your travel time like lawyers, so it’s nice to have some way to offset costs; i.e. being able to work. Trying to type on your laptop in coach is torture vs. first class.

Expense Reporting

A lot of consultants, even if salaried, are required to document their time and expenses. This means documenting, usually in some web based time tracking program. Thus, you need to be aware of how much time you’re spending on tasks, what those tasks were, and how much more you think you’ll do. This can get tricky, too, when you end up in a staff aug position and basically end up running the project. Suddenly you’re holding the ball, and people are wondering why you’re billing time for meetings vs. coding… you can get into really uncomfortable, and extremely irritating and unfair situations. Examples include being the architect & mentoring company employed developers on the project, and when the UAT comes up at the end of an Agile SCRUM Sprint, you show zero User Story points completed, and people in charge question what value youâ€re providing.

If you document well, cya (cover yer arse), and have transparency with the client into what you’re spending your time on by talking to them early and often, you’ll do fine. While they often don’t plan for you to spend a lot of your time in meetings for doing architecture, as long as they’re aware that out of 4 months of billable hours, 2 months were spent helping the client align their processes to ensure they could support the app, ensure the user stories/features in the application were valid, and the design was actually capable of being built… then you’ll at least get paid.

Document your time, be aware of what you’re working on, and what you need to work on. Communicate what you’re doing for the client often.

Meeting the Client and Its Stakeholders

I like meeting new people. I like talking. I like meeting successful people and learning from them. Consulting with companies that desire your expertise teaches you a lot about software that supersedes the construction of it, but how it’s actually consumed and sold. This makes you question a lot of the commonly held beliefs by OOP Purists and other fads touted in the news. It’s awesome. You get to learn how to build software, how to fix it, how to align teams, how to prevent fire drills, why you’d even want to prevent a fire drill, how to compromise amongst silo’d departments, how itâ€s sold… the list goes on and on.

To get things done, and get bigger problems resolved (like using the wrong technology stack/methodologies/processes), youâ€ll have to meet & talk with the big wigs. If you arenâ€t comfortable talking with upper level management, having an MBA helps. If that isnâ€t your thing, find someone who is good at it, and learn. Sometimes these are either A) the only people that can move you forward and/or B) theyâ€ll great at articulating why youâ€re so effâ€d and just need to deal with it.

Bottom line, you can get the REAL story behind why the way things are, and exactly where they are going by talking to project stakeholders vs. the variety of “this is my world at this company” responses youâ€ll get from interviewing employees who arenâ€t Director level or higher.

Offering Professional, 3rd Party Opinions

Often youâ€re firm will be hired for your realm of expertise. Other times, they already have the expertise, whether internal employees or another firm, and just want your opinion as a 3rd party who isnâ€t currently involved nor has stake in the current project. They actually care what youâ€re opinion is and pay for it. This helps them confirm what they already know with an “iron clad” assessment, or perhaps challenging strongly held beliefs in a certain section of the company.

Sometimes these validations, such as:

“Yes, this other consulting firm is billing out a bunch of n00bs to you for $150/hr, and yes, youâ€re internal employee DID in fact build something amazing in 1 week what the 2 n00bs couldnâ€t do in 3 months.”

…lead to consulting engagements. Sometimes confirming what the company already knows builds trust, and thus leads to a longer term engagement.

Other times youâ€re actually hired for a less valued position such as staff augmentation, but youâ€re experience/knowledge ARE in fact beneficial the project. Thus, you need to find a way to ensure those who need to know learn about what you know. If you sucked, you wouldnâ€t be hired for your high price, thus, ensure the client gets value from you via your professional opinions.

Dressing Nice

Iâ€ve mentioned this countless times before. Clothes make the man. Women typically dress to impress other women; in this case, women need to dress to impress the client. Business casual is usually ok, although, the larger the account, the more formal you need to look. In my opinion, you CANNOT be overdressed for an engagement. If someone mentions on the side you donâ€t have to, theyâ€re either threatened, or donâ€t understand the game.

Dress to impress. If you look impressive, you must be impressive. Youâ€re thus apparently successful because youâ€re knowledgeable. This includes accessories such as the car you drive, the bag/briefcase you carry, and the business card you deploy.

Attending Meetings for a Company You Donâ€t Work For

Sometimes, especially if you end up being a shield for the rest of the team, or if you just want to learn about the lay of the land, the players, and all the drama, youâ€ll need to attend company meetings. These are often a waste of time, or things to be avoided at all costs. However, to management, THIS is their transparency to give to stakeholders at some companies. Providing attendance by your firm is often a requirement.

Either way, youâ€re involved in the project, and need to attend the meetings, and sometimes participate. Sometimes you even need to call/create meetings (OMG, the horror!). These are usually to get consensus from the team on an issue that you couldnâ€t do in SCRUM, or resolve drama, or to brainstorm on how to solve some challenging coding issue.

Interviewing/Hiring Members for Your Team and/or the Company’s on the Company’s Behalf

Sometimes youâ€re brought onto a project, and realize you need help. The company looks to you to “build it” or “fix it”; if that means more developers/designers from your firm, so be it, theyâ€ll find the budget. Getting resources can be challenging. At a smaller firm, you may have to have the resources yourself already ready to go. David Ortinau, one of my mentors on this, has helped me create a spreadsheet of people Iâ€ve met over the years. On it, I list out people Iâ€d hire (and who I wonâ€t ever hire), what their speciality is, and what the last rate I got them for was. This is because they are often working for me. Even at my firm, my partners are uber-busy, so I canâ€t immediately assume theyâ€re always available. Obviously theyâ€re my first pick to work with.

If youâ€re with a larger firm, they can often help in 2 ways. First, they can provide you additional consultants if the client has the budget for it. Secondly, they can sometimes provide resources from other firms. This is more challenging because usually the other firm will want their cut of providing a resource. This means, either your firm makes less revenue from that resource, or justifies the lack of serious profit from your dire need…. or both.

Other times, the company is looking to maintain the solution/software you/you and their team has created. This means hiring employees that work for the client. They’re responsibilities include adding features to & maintaining that software. Often, youâ€re the most qualified to hire said employees. Interviewing potential coders is a challenge & learned set of skills in and of itself.

Getting Out of Consulting

A profession that provides a significant amount of money, a huge opportunity to learn, and networking opportunities with new people & companies seems like something you wouldnâ€t ever want to leave, right?

Wrong.

Consulting has a lot of overhead on the soul. This includes the following:

• copious amounts of travel to be on-site wherever the client is. This is time away from your loved ones.
• dealing with incompetence where said incompetence cannot be fired/laid off, yet continues to actively sabotage your project and/or client relationship.
• dealing with politics that theoretically help the companyâ€s stockholders, but ensure the software team is setup to fail
• various implementations of Agile SCRUM that arenâ€t true to the tenets of SCRUM, and thus donâ€t see the benefit of it. A lot of times, this angers everyone involved in the team including the PMâ€s running it, and is just a gross feeling.
• You potentially never “love the code” youâ€re working on.
• The ultimate consulting goal of “leaving the company better than you found it” may potentially be unknowable in how to do so.
• Entropy is scientific fact that all things eventually will return to chaos. Youâ€re constantly fighting this in consulting/leading large teams regarding the code base; this can take an emotional, and spiritual, toll.
• Sometimes, companies pay you lots of money to produce code that never sees the light of day.
• Sometimes, companies pay you lots of money to code in an IDE you loathe on an OS you are unfamiliar with using a framework you hate implementing design patterns you disagree with amongst a team who doesnâ€t understand why youâ€re unhappy with the status quo.
• If things go sour, you can sometimes not get paid, or take awhile to get paid.
• Depending on the team, the complex processes involved on the surface appear to provide no value to the project and prevent developers from actually writing code since they’re in meetings or writing docs instead.

Add to that the paperwork around expenses & taxes, and itâ€s an enough to make anyone want a salaried job. A steady, consistent paycheck with easy taxes. Sometimes way less stress, too.

In most cases Iâ€ve seen a change of scenery, a long vacation, or just a different project is enough to rejuvenate even the most burnt out consultants. Other times a dive back into the W2 world is a great vacation from consulting.

Just be aware there is a huge pay scale difference between consulting and non-Enterprise salaried positions. Just because you take a salaried, full-time position at a large company because they offer comparable money & benefits doesnâ€t mean youâ€ll actually be able to use your consulting skills. There is a lot of power in not working for a company directly. You can get away with telling them off for being incompetent, explaining how to get out of the mess, and theyâ€ll thank you for it. You do that as an employee, you typically get a different reaction, one you donâ€t want.

Bottom line, this can make finding comparable employment & compensation challenging if youâ€re thinking of getting out. From a skill set perspective, usually only start-ups need someone of that caliber, and unless they have known backers, itâ€s hard for them to afford you unless they offer some serious equity.

Conclusions

Consulting is a profitable endeavor, usually involving your skills on larger projects for larger companies. You can work with various teams or simply offer your expertise, perhaps via training. Itâ€s a great opportunity to learn, meet new people, and discover the business of software and the development processes various companies use. The money canâ€t be beat, either. The easiest way to get in is to find an existing firm such as Universal Mind or Deloitte and get hired.

The skills required are more demanding that normal freelance software development. Specifically, knowing how to architect extremely large applications, having good leadership skills, and the ability to communicate complex subjects succinctly are key. These skills can be learned and practiced.

Consulting is a demanding career choice and itâ€s ok to take a break from it. Being an expert in your field requires you to be constantly researching, learning, and being on top of your game.

Keep in mind, too, you can work for a consulting firm and “just code”. This isnâ€t consulting, though.

This article will discuss what Technical Debt is from a Flash/Flex developer perspective, how it negatively affects my Scrum projects, and what are some of the prescribed ways to prevent it.  Nothing ground breaking here folks, just corroboration that TD IS a major problem, and not even Scrum is immune.

What is Technical Debt?

Martin Fowler has a good summary about what Technical Debt is.  Here are 2 quotes from his wiki:

You have a piece of functionality that you need to add to your system. You see two ways to do it, one is quick to do but is messy – you are sure that it will make further changes harder in the future. The other results in a cleaner design, but will take longer to put in place.

Git-r-done vs. doing it right.

Another quote which describes the metaphor:

…doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt. Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice. We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline. The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

He goes on to mention that unlike money, you cannot effectively measure technical debt. Additionally, you only get a return on your loan once you deliver.

Signs of Technical Debt

There are various signs of Technical Debt.  System fragility, tons of reoccurring bugs, or code that “sometimes” works.

System fragility examples include when you move a login button, the entire login form doesn’t work.  Another sign is when you change a ValueObject’s property name slightly, yet get no new compiler errors.  Yet another, usually a violation of DRY, is when you change a parsing error of a server’s response, yet still get the bug after compilation.

Another example is the statement “the application doesn’t seem to be working”.  If there had been diagnostic tools in place such as unit tests, a debug/log window, or other testing tools, that question could be quickly answered.  Even if it can’t, if you can’t quickly isolate problems after asking some follow up questions, that’s another indicator.

Another is when you fix a bug. 3 times. Over 3 Sprints.  Then it comes back in some other unrelated area.  Another is before the user even does anything you’re presented with one or more error dialogues.

The best are when you see the right data.  Sometimes.  You have no idea if it’s your fault, the server’s fault, or… what.

Bottom line the code has growing pains, and is challenging to change.  When you change one thing it breaks something else unrelated, your change is a pain to implement, or your new code duplicates a lot of functionality because you can’t borrow other functionality because it isn’t encapsulated enough to share.

The one that took me a LONG time to get over when I first started dealing with extremely large code bases was “fatique”. I’d get tired of dealing with all the problems, and feeling like I wasn’t making any progress. That, and I had no confidence in my changes because I wasn’t sure what the ramifications were, what would break, etc.  Effectively, I didn’t want to work on the project anymore. This has happened twice to me.  It’s not from my attention span, but rather just pure loathing at not being able to move forward.  Part of this is remedied in experience, part in “learning the story” of code base by spending a lot of time with it, and just general growth as a programmer. If you’re grown, and still have this fatigue, that’s another clue.

All these and more are signs of Technical Debt.  If not dealt with, they only get worse and more numerous.

Technical Debt’s Effects on Scrum

In Scrum, your user stories need to pass User Acceptance Testing (UAT).  At the end of every Sprint, your client validates each user story your team completed is in fact done.  If you have technical debt, this’ll eat away at the quality and/or dependability of your user stories actually working.  This means one or more stories won’t pass UAT.  This then slows down your, or your team’s, velocity.

This often will negatively affect your client’s view of the team as your earlier velocity will have been higher.  Usually your team will start off slow or fast, but eventually 4 Sprints in, a common velocity will emerge.  With a lot of Technical Debt, the reverse will happen; your initial speed will slowly decrease as your team struggles to cope with the increasing Technical Debt.  If not tackled, more debt is created, and your velocity stays slow, or decreases.

Technical Debt will also often exhibit itself as “bugs”.  In Scrum “there are no bugs”.  Benevolent Scrum Masters will assign 1 point to bugs.  This is often done to put a sense of accomplishment that the bug was completed, but more importantly that it’s trackable.  Its low point value can unfortunately skew to its business value.  Perhaps the bug is what prevented your original user story worth the maximum of 5 points from passing UAT.  Worse, if your team is working on fixing bugs, they aren’t working on user stories.

Again, negatively affecting your velocity.

Eventually your team will either have to pull back and pay off their technical debt, continually pay off a little to show some payoff, or just pray the client focuses on more pressing user stories in other areas and “forgets” the glaring issues.  I’ve seen all 3 happen.

Pullback & Reassess

Scrum doesn’t really have methodology for pulling back and fixing core architectural problems.  It’s generally assumed that 80% of your 2 week Sprint is spent refactoring.  I’ll let that sink in.

Done?  Worse, Technical Debt, being unmeasurable, wreaks havoc on a Product Manager’s ability to give transparency into the project for stakeholders.  You don’t often have a stable velocity; some Sprints your team could simply deliver 0 story points.  This makes it challenging for the PM to project when the Backlog will be completed and when certain milestones will be reached.  It’s even worse when managing budgets and getting contracts signed.  Scrum is hard enough to sell to clients who are used to fixed bid; suddenly Scrum sounds like a bait and switch, or just a money pit.  Assuming your team is actually working on the user stories they were assigned and aren’t trying to sabotage the project, then that situation is usually irrefutable proof that your team has some serious Technical Debt.

Software done with Scrum is like a plane flying from A to B.  While the flight path is continually corrected, eventually it’ll get there.  Planes usually can’t fly with ice on the wings, hence why you setup good architectural bases in the first 2 Sprints.  Ice on the wings during flight can be disastrous.

For some projects, sometimes you have no choice.  Your team has to take the hit, pay off the debt, and rebuild trust with your client.  Yes, these can be bloody, but hey… anything is better than Waterfall which in my experience ends like Lock, Stock, and Two Smoking Barrells: Tons of death, theft, and people get bling who don’t deserve it.  While this is effective with Capitalism, life is too short to product shitty software.

American Credit

While not an American only phenomenon, it’s certainly indicative to our culture, hence why Fight Club had such an interesting ending.  If you’re quick, good, and lucky you can get away with paying as much Technical Debt as you can per Sprint while knocking out a few new user stories as well.  Sometimes this is just how things are; other times, you’re merely postponing the inevitable day of reckoning.  Consultants are famous for this.  They get away with masking the massive Technical Debt, and moving on letting some other poor W2 (employee) sap, or consultants like me, to actually fix the Technical Debt.

Eventually, you have to fix the broken windows… or maybe “you” don’t, but someone does.  It’s easier to do this sooner than later.  I’ve even seen a team where one guy would fix windows 90% of the Sprint, and another would unintentionally break them again.

Pray for Priority Shift

The third one I’ve seen happen in larger companies who don’t adhere 100% to Scrum.  The priorities change for the user stories, and other parts of the application which are basically broken are ignored, buried, and eventually assumed to work.  Flowers don’t grow as well over a dead robot’s grave.

Incidentally, when higher ups find out, this is where I get some of my work.

Preventing & Fixing Technical Debt

As you can see, Technical Debt has devastating effects on Scrum, and Iterative Software in general.  The best way to ensure Technical Debt doesn’t negatively affect your project is to prevent it.  It’s like insect infestations in your house; if you don’t attack the problem early, it can be very challenging to remove.  The best way is to prevent the infestation in the first place by not leaving out food, water, and generally ensuring you have sealed entryways and windows.  Same with software.  Start with a tight, simple architecture, and continue to maintain it.

That sounds great from a high-level perspective, but what does that really mean?

Here’s a few I know & have experience with:

• good design
• good developers
• fixing broken windows ASAP
• OOP, specifically encapsulation
• unit tests with a decent coverage
• an agreed upon framework
• throwing optimization out the window
• using old technology
• Continuous Integration: frequent checkins & religious tagging

Here’s a few I know of, but don’t have a lot, or any, experience with:

• Test Driven Development
• Automated Build Systems
• Automated Testing (Hudson, Cruise Control, etc)
• Functional/Automation Testing (QuickTest and others)

Let’s go over these in short detail.

Good Design

The #1 thing that saves you the most time, reduces the most risk, and directly contributes to the efficiency of your team is a good deign.  Wireframes you hate since you’ve re-worked them so many times with gallons of dead tree’s at your feet, and design comps you love.  5 minutes of a designer’s time can save a week of a developer’s.  When you hit a brick wall during Sprint 5, a designer can quickly put your team back on track quicker and more accurately than a developer can.

Hire, and keep around, a good User Experience/Interaction Designer/Information Architect/Designer today!  If you’re made of epic win, hire a Usability Engineer as well.  They are the ONLY ones who can provide real facts to your team.

Good Developers

A common complaint of Scrum is that it only works with senior to mid-level developers.  I agree.  While it takes a village to build great software, you need to ensure your development team is top notch, or mostly top notch with a rockstar to guide the rest.  I realize this isn’t a reality for a lot of people.  Even if you have a senior dev, the bad developers can actually detract from the senior’s ability to deliver as he/she struggles to re-factor their code while ignoring their own user stories.  That or the bad/mediocre developer continually creates Technical Debt.  While developers not focusing on their user stories is a management problem, not a Scrum specific one, if they can’t even be professional and do what they are told, they are effectively sabotaging the project, and thus need to be removed.

Remember, small agile teams are more effective than larger ones.  If it ends up only being 2 heavy hitters, so be it.  Or you can just hire my team.

Fixing Broken Windows

Not much to add here other than they are usually one of the few things that can clearly indicate Technical Debt.  If you have to prioritize, choose to ignore the ones you can easily predict and reproduce.  They are less dangerous and take a lot less time to annoy your clients.  It’s when you go, “Whoa… never seen that happen before” is when you worry your client and PM.

OOP Encapsulation

One of the good concepts of Object Oriented Programming is Encapsulation.  It may seem silly to bring up something so basic, but it’s a basic, core concept for a reason.  Without good encapsulation, your code cannot grow, nor be flexible; something that’s VERY integral in Iterative development.

It’s ok if your API is good and the code underneath it sucks.  This is where Test Driven Development can shine.  Instead of “creating a component” from the inside out you actually write like you’re going to use the component yourself.  A better API usually results.  Then, you can focus on writing the guts to make that API happen… or not (see throwing optimization out the window).  It’s easier to fix bad code inside encapsulated, and thus easily isolatable components than it is sphaghetti code.  Sphaghetti monsters are waaaayyyyy more scary to fix than WW2 tanks that just need a new engine.

Unit Tests with Decent Coverage

Even if you don’t practice TDD, it’s still a good practice to implement unit tests on problem areas of the code.  TDD purists will state you should write tests first.  If you don’t, there is still a ton of value in writing unit tests, or getting good “coverage” of problematic areas.  Key areas include your Service layer or any code that accesses non AS3 data and injects it into the system.  This includes XML, text, JSON, AMF, binary data, and anything that “parses” something.

Strong-typing is awesome, but it assumes you started with strong-typing.  Parsing XML to ValueObjects is great, but if “That PersonVO is a Spy!”, good unit test coverage can usually point that stuff out early and save the team days of debugging and lost time.

Plus, it’s really awesome to blame with 100% confidence the back-end Java team for your woes in 7 seconds vs. 2 hours of frustrating searching for a needle in a haystack whilst being verbally bashed by the back-end devs wondering why you didn’t use HTML5 instead of Flex.  Suddenly Outlook does a cliche freeze before you can write a scathing, emotionally charged, career destroying email back at those over-architecting ($*&Us.

While they have less value on GUI components, some of the ways in which you architect Flex 4 components can actually facilitate easier testing.  Examples include really complicated components that NEED to be in a specific state when data is injected.  While a really complicated chart that has 100 unit tests around it still has to be visually verified, those 100 unit tests can help dramatically.

Finally, in those areas where you have good coverage, you can do minor refactoring with a ton more confidence.

Agreed Upon Framework

Doesn’t matter what framework your team chooses, as long as you all are in agreement.  This could even include using no framework.  I prefer Robotlegs, my partners prefer Swiz, and my clients often still use Cairngorm 2.x.  Regardless of your thoughts on frameworks, in my experience they help you manage, scale, and work with a team on larger code bases.

Premature Optimization

Knuth once said:

…premature optimization is the root of all evil.

After awhile, common optimizations you do by default, and to me, aren’t even considered intentional optimizations.  Some are small, low hanging fruit, that you can do without even thinking and make into habits.  Examples include setting an Array’s length to a local variable instead of inside of a loop, using Object Pooling, and using visible vs. removeChild.

Good programmers constantly want to make their code better.  Sometimes this means faster or more responsive.  The really good ones know when to leave a TODO, and move on.  Most users are happy with a reasonably responsive GUI.  A programmer’s expectations of “responsive” is often way higher than what a user will accept.

Code it and refactor later.  You can’t refactor vaporware.  Focus on pimp API’s.  Besides, this is ActionScript, not C.  We have certain limitations (no threads, a VM vs. all code being machine code, and a lot of missing optimizations).  Brandon Hall once said if you have a performance problem in Flash, you’re probably doing it wrong.  Instead of re-factoring code, step back and re-assess your approach.  Recognize those limitations early, and yell like crazy at the designer, “WE CAN’T GO TO THE MOON IN A TRICYCLE YOU FRAKIN CRAYON PUSHER!!!?”

If you have something to prove, do it at night and post to your blog.  If the GUI isn’t responsive, well duh, that’s not a bad optimization, that’s a required one.  The point here is if you need to prove through tests cases that by not doing your optimization(s) that the app will be unresponsive, you’re either in dangerous time sink territory, or doing something amazing.

Use Old Technology

While I love using Flex 4, a lot of the apps I still work on, and clients have in development and/or production are Flex 3.x.  Flex 3.5 & Flex Builder are solid, 4.0 SDK and IDE, not so much.  You want your problems to be programming challenges, not unexpected scrollRect or IDE magically disappearing code hinting bugs.  These things can be major time sinks and devastating to your productivity, sometimes killing your entire day as you attempt to reinstall & reconfigure various things.  Mitigate those risks by using old software that works and has a proven track record.  Most won’t listen to this paragraph and I don’t blame them.  Flex 4 skinning does help a lot in the “make this design work” department, although, no one talks about the overhead costs of putting an icon in a Spark button, and all the other simple things that are now more complicated.

Software traditionally outlives it’s original expected lifespan by 3 times or more.  One of the reasons is that it works.

Continuous Integration

Continuous Integration is a gigantic topic, and actually encapsulates a lot of other sub-topics I’ve already mentioned.  I just want to focus on the parts of it that I found extremely helpful and harmful if not followed.

The first is checking in your code often.  If you don’t know how to merge code, learn.  If you don’t know what tool to use, use BeyondCompare.  If you’re on a Mac like me, use CrossOver to make BC work (I’ve been using that setup for 4 years).

Even on a 2 man team, merging and testing your changes can take a lot of time, even if you and the other developer are on completely different sections of the code base.  On one project, we actually set a specific merge day on the 2nd week of our 2 week Sprint to ensure we planned for this disruptive day.  We’d both merge frequently, but we’d still ensure we didn’t merge much more after that since it can wreak havoc on UAT day.

Regardless of what source control system you use, you NEED to implement tagging.  This doesn’t need to be a team thing at all; just give 1 person responsibility with this important task.  Every UAT day, they need to tag the build.  Developers in general should make their own tags and branches, but sometimes the code isn’t in a risky spot and you don’t end up doing it.  That’s ok.  You should still have Sprint tagged builds so you have SOME saved point to confirm/deny major bugs/changes against.

Test Driven Development

I won’t go into detail here, but I’ve seen the positive benefits on my Service layer, or when I’m writing a library for others to use.  For both, you actually create the API first and it feels immediately relevant.  Additionally since the Service layer is often the weakest link in your application it’s great to proactively find bugs that would of usually cost a lot of time early on.  That, and you have a dependable suite to test for changes that may negatively affect things later on.  Finally, you can test if the entire applications communication system is working within seconds, quickly killing assumptions that add to debugging time.

What I haven’t resolved yet, and this is probably due to my inexperience with it, is how to manage the amount of code I have to refactor.  No longer just the components, but the tests often as well.  This is especially true with some of my more complicated GUI composition components where I test the controller layers.  Maybe it’s my inexperience with TDD & unit tests, maybe my tests just aren’t very good… I don’t know.  Like any problems with the GUI, I just blame the Designer.  That doesn’t make the re-factoring amount & time go away though.

Automated Build Systems

Automated build systems include things like ANT and Maven or even Rake.  This is the #1 question that sabotages my sales call when talking to Enterprise clients.  They want to here me say, “Why yes, of course I’m a major proponent of automated build systems.”

I don’t, though.  ActionScript & Flex Dev isn’t Java, and is a lot simpler.  I’ve seen more team productivity lost to setting up & maintaining build systems.

… except for deployment.  When you’re deploying to various servers, and doing integration testing with different systems, I’ve seen TONS of value here.  I’ve only seen this work if you have a dedicated build person who doesn’t mind having a lower story point contribution.

If I can’t hit the run and debug buttons in Flex/Flash Builder, I perceive that a serious problem.  I’ve seen many teams who can’t do this, and fire drills rage.  Once you solve that problem, you can start tackling other problems.  There are many who disagree with me, but they are nowhere to be found on my consulting gigs where I’m saving a project.

Automated Testing

The King James Bible says in the 10 Commandments that you shouldn’t covet your neighbor.  I’m an uber-sinner then because I’ve never worked on a team that had the chops, client permission, and/or resources to setting up and maintaining an automated testing server, yet I continually wish I had been, or soon will.  I’ve been on teams where we talked about it, but it was never executed because we too busy TRYING NOT TO DIE AND ACTUALLY SHIP SOFTWARE.

Hudson and Cruise Control look awesome.  That said, a lot of the people I’ve worked with don’t even write unit tests, so……..

Functional Testing Tools

As I stated, a lot of things in Flex are insanely visual; you can’t write unit tests to test visual accuracy.  That, and some of the state’s they get in are unwieldy to write tests around.  You can utilize functional testing tools to automate a lot of that… and man, seeing them in action is HOT!  They are wicked expensive as a result, and only the larger Enterprise companies employ them.  Here, too, is another thing that sabotages my sales calls with clients:

“You ever use Functional Testing tools?”

“No, but I’d love too, they look HOT!”

Conclusions

In my experience with Scrum, and Iterative Development in general, Technical Debt is the only thing I’ve seen that can really destroy the promises that Scrum is supposed to deliver on.  Thus, it’s been the one thing I’ve been focused on better understanding on how to identify, prevent, and fix.  If you’re using Scrum, beware.  Twice I’ve seen Technical Debt make a huge negative impact on my projects.

There are a bunch of things you can do.

Think heavily upon the decision of coding something quick vs. planned out well architecturally.  There are pro’s and con’s to each (OOP Purists will tell you nothing should be quick, they are wrong).  Sometimes you have zero clue if feature is even relevant to the your users, and it makes huge business sense to only make a quick foray vs. a huge, heavy architecture investment in case the user quickly scoffs at the functionality.  Patton called this a “calculated risk”.  Software IS War.  Other times, that quick implementation without any good architecture can have major negative consequences later down the line.  That’s ok, though, just get really good at refactoring.  Yes, it’s a skill you can learn.  Yes, refactor is a good word; it’s not the same thing as rewrite, and is integral to developing software well.

The other ones are ensuring you have a competent team, ensuring they follow commonly known practices, and tackle problems early.  Check your code in often and early.  If you don’t employ TDD, at least think about getting some unit test coverage on areas that continually are causing problems.

Remember, part of this recession was caused by people having massive debt they didn’t deal with, and ignored.  Debt is a valid way of doing business, and so is software, but you need to see some eventual value on that investment, and not let your debt get out of control.

If you ignore everything I said above, just remember 3 things: encapsulation, refactor, and use a damn good logger.

Caveats

I continually abuse 2 terms below, Backlog and Sprint.  Sprints don’t have to be 2 weeks, but for the sake of simplicity, I assume they are.  Also, Backlogs contain user stories, not requirements or features.  However, I assume for the sake of this article your features are already formed into user stories.  Finally, I assume that once I capture a requirement, it’s thrown into the Backlog.  I actually have a document which holds the validated requirements, which I then later formalize into user stories, and then put those officially into the real Backlog.  In this article’s case, that process is assumed to have already happened.

Review: What is a Backlog?

First, a review. A Backlog is a place you store features, or user stories. There are often 2 Backlogs for a software project, a Product Backlog and a Sprint Backlog. The Product Backlog contains all features for your software. At it’s purest form, it’s an spreadsheet that lists all the things your software is supposed to do, with a rated business value. While it can be seen somewhat as a requirements document, it is more defined, and singularly focused. It merely lists features/user stories.

While a requirements document may say “The application needs to allow users to register and login”, the Product Backlog would probably have that as 4 line items:

• Upon entering [product URL], and the user isn’t logged in, they’ll be presented with a login screen. They can enter their username and password, click the “Login” button. If the correct credentials are provided, the user is shown the landing page.
• If the user inputs the incorrect username and/or password, the Login screen is shown with the error message “Your username and/or password was incorrect”.
• If the user is already logged in when entering [product URL], they are automatically taken to the landing page.
• If the user does not have an account, and arrives at the login page, they can click the “Register” hyperlink to be taken to the New User Registration page.

There are a lot more user stories you can write, or even refining the ones above. There are a few points here in the difference. The client wants users to register and login. This requirement can easily be documented in a requirements document. That requirement belays a lot of work for developers, and a lot of things for the PM to track. Requirements are for capturing the client’s needs, but are not setup for clearly laying out what a developer should do, nor what the acceptance criteria is. The developers want clear instructions on what they are supposed to code with a clear acceptance criteria. Most importantly, the Project Manager needs to have trackable items, clearly documented, that are accepted by the client. Additionally, she needs to have weights and priorities attached to these items so she can track over time and give the client transparency into the project.

These units of work, called user stories, are stored in the Backlog. They are mutually agreed upon by the client, developer(s), and the PM.

Review: Sprint Backlog

A Sprint Backlog is where you put features/user stories that team needs to complete each Sprint. You put user stories into the Sprint Backlog from the Product Backlog. Once the Sprint starts, the Sprint Backlog becomes frozen. While you can add & modify things in the Product Backlog while the Sprint goes on, you cannot add/modify things in the Sprint Backlog. Additionally, the Developers are the only ones who actually mess with the Sprint Backlog. They’ll assign user stories to themselves, complete it, and move to the next.

What Are We Building?

One of the reasons for the high rate of software project failures is due to the software not being what the client wanted. Software is usually built to a specification or “spec”; a document that outlines what the customer/client wants. Clients are busy. Thus, back in the Waterfall days, you’d get a sales and/or PM to document as much of the client’s requirements as possible, formalize it into a contract, usually a Statement of Work or similar, and have both parties sign it. This contract was supposed to be what you were building, by when.

There were 3 huge problems with that. First, it assumes you accurately captured requirements. This is a fallacy. Communication is a flawed process based on the filters we humans use to understand other humans (my mind filters the thought into speech I believe you need to here, you hear this speech and interpret the meaning of my words, and filter it to what you think I said). Thus, you need to, rightfully, assume any documentation, even mutually agreed upon, is flawed.

Second, developing software is slow compared to making dinner. The business and/or customers who needed the software can change.  Software needs to embrace change to be relevant.  Iterative development embraces that concept whereas Waterfall does not.  Waterfall assumes you got it right “months ago”, and there is no room for the client to change their mind.

Third, it’s a myth that people can tell you what you want.  Clients think they know, even if they are actually involved in making software, but they don’t.  Usability testing is the only proven way in software to validate if your software works or not.  To do usability testing, you need to have a working build of software.  To have a working build of software, developers have to make a build vs. work on the build.

Iterative development forces you to make working builds every 2 weeks, and gives the client the opportunity to validate that your implementation of user stories are actually valid.  This also allows them to validate the software is solving their current needs, and if not, they can shuffle the Product Backlog around, and re-prioritize for the next Sprint.

The Product Backlog contains all of the features your software has, and the Sprint Backlog has the frozen features your team is implementing this Sprint.  The key here is that the Product Backlog can change.  Whether your client wants to re-prioritize, or they have new things they want to add.

Scope Creep

Scope Creep is defined as the scope, or total requirements for a project, growing over time.  The word “creep” is used to imply that it’s growing beyond the originally agreed upon scope, and it’s doing it slowly enough not to raise the ire of anyone beyond those actually designing & developing the project.  It’s the bane of web & application developers everywhere.

Unless you use a Backlog in Scrum.

If the client wants to add new functionality, they can.  Adding new functionality to a project is often a good thing.  Whether a good idea that could of only arisen AFTER a build of the software was used by the client, or a glaring hole in available functionality was noticed weeks later.  Sometimes the new functionality is just a piece of functionality re-stated, but with additional work behind it.  Developers usually hate this because while the client perceives it as “the same scope, just re-worded”, developers know that it’s 3 times the work.  First, they already built it; second, they have to re-work their existing work assuming it can be re-factored at all; and third, they still have to code all the NEW functionality added…

…within the same timeline.

Unless you use a Backlog in Scrum.

Remember, the Sprint Backlog, the things developers are working on during a given Sprint, is frozen once your team starts.  It CANNOT be changed once you start.  The client is welcome to modify, change, and re-prioritize the Product Backlog whenever they want.  If the functionality your team delivers at the end of every Sprint meets UAT (User Acceptance Testing… also known as “we built exactly what you asked”), and the client wants to change it, it’s added as a new feature to the Product Backlog.  This is huge.

This means that anytime the client “adds” or “changes” something, it’s clearly documented in the Product Backlog.  The key here is if your team already delivered a user story from the Sprint Backlog, and the client wants to change things, they can’t magically undo the completed user story your team completed.  It stays completed, and a new one is created for insertion into the Product Backlog.  This is a track record for the PM and your team to clearly show they client they ARE adding scope the project.  Your team IS delivering on what they were asked to do.

I don’t want to get into teaching the client, managing their expectations, etc. I just want to point out here that’s how it’s supposed to work, and that’s fine.  Most Product Backlogs grow as the project moves forward.  This is a good thing.  It shows things are evolving and getting refined.  Your client is getting what they want.  Your team is shielded from scope creep sabotaging your work and the client’s expectations.

Product Development Helper

I’m involved in 2 products currently.  One is an Enterprise Dashboard Framework for my company, and one is an image app I’m working on with Joel Hooks.  Both projects were well under way when I was brought on board.  Both project owners specifically asked me to join to help them accomplish 2 things.

First, they wanted to launch.  Second, they wanted an opportunity to do Scrum development.

While I have gleefully accepted helping them reach these goals, this put me in a few challenging situations.

Economics of Design Phase

From my experience in software, I’ve found (and read online to corroborate) that the most impact with least cost is spent in the Design Phase.  This is when the User Experience (UX)/Interaction Designer (ID)/Information Architect (IA)/Designer people/person figures out what we’re building.  To give you context, let’s pretend I charge $50/hr (<– lol!) and conveinantely leave out the design part (where wire frames are made to look hot via Photoshop/Illustrator/your mom):

• 2 hours spent on wire framing a Login = $100
• 16 hours spent coding the Login to work = $800

Now, the ratio varies, but typically development time greatly exceeds time spent wire framing.  There is also a dependent relationship here that the above math doesn’t show. Attention to detail & well thought out user stories implemented in the wireframes often significantly reduces the amount of time developers have to spend.

• 2 hours spent refining registration = $100
• 6 hours saved by devs not having to stop, lose momentum, ask questions, get clarity, re-work, wtf = $300

Another advantage is “cheap flexibility”.  If you want change your mind about something in Design Phase, it’s really cheap.  I’ll often utilize a pen and paper for creating software, whether that’s in the beginning, or after we hit a design/functionality challenge in the design comps and we have to go back to the drawing board as it were.  Drawing boxes and arrows, and then summarily ripping out the piece of paper for 2 hours until we get it right.  This, as opposed to having developers figure out mid-sprint, costing them valuable momentum, and setting them up to fail.  …and costing a lot more money.

• 4 hours playing around with the Landing Page = $200
• 2 days using developers to play around with the Landing Page = $800

Keep mind, your Designer doesn’t contribute, nor is beholden to, Story Points.  If you utilize your Developers to experiment, you’ve detracted from their ability to deliver on their committed stories.  This costs you twice: Their lost productivity they’ll have to make up, and by spending more money using developers vs. designers to play around with a design.

False Starts

I’ve tried & failed enough times at launching my own product ideas that I’ve learned what not to do.  The #1 problem I ran into was lack of design direction.  As a single man team, I had to do design, front end & back-end development, and product management.  That’s hard.  If you know the idea, the market, and are passionate about it, you can actually do pretty well simultaneously performing all of those roles.

However, as a coder, I naturally spend way less time on design.  That was consistently a mistake I paid for. It absolutely annihilated my momentum.  More importantly, as I got frustrated I didn’t have design direction, knowing I’d have to stop coding and do more upfront design work, I lost the will to continue.

Once you lose the will, you’re screwed.  You won’t launch.

Design Phase vs. We’re Almost Done

Thus, for both projects, I’ve spent a lot of time on the design phase.  This means everything from documenting what we’re doing, drawings and wireframes, and keeping track of our Backlog.

The problem is, both teams are rearing to go… they want user stories to munch on with Sprints.  The old adage here, “garbage in garbage out” still applies to the Backlog as well, thus I’m sticking to my guns.  While we collectively could extract what user stories there are, and sort by priority, without a good design to guide those user stories, we’re just going down a misguided path with awesome equipment.

I haven’t figured out how to manage this.  My only saving grace is that I can easily remember back to when I was “just starting” or “re-starting for the 4th time” that my will was waaaayyyy harder to break in the beginning; it was only once I had been working for 3 days straight, and hit a design brick wall that it crumbled.  However, if I was just thinking and playing around, my will could stay strong for months.

We Need To Do This Also: Work Intimidation

Both projects have their challenges.  For the Dashboard, I know the audience, so it’s pretty easy to wireframe for it, and outsource the design.  For the image app, I have no clue who they are, and the descriptions I get from her majesty and Joel, I can’t relate to.  So, I had to create Persona’s, validate these persona’s, and then create goals from them.  Even simple goals lead to a lot of software work.

Another problem I found with trying to launch a lot of my own products and failing was breadth of work.  Not scope, but the amount of goals the software was trying the accomplish.  I’ve found the amount goals you’re trying to solve is directly proportional to the amount of work you have to do.  I was only successful when I targeted a reasonable amount of goals to the created a somewhat reasonable amount of work.

At first, you think “man… that’s ALL the software does?  This’ll be easy… and disappointing.  There’s not much of a challenge, and I’m not sure my users will like software that doesn’t do a lot.”

Bullshit.  If you believe that, you’ve never launched software.  I believed that, then I failed 50 billion times trying, and eventually gave in, and tried to launch even something mediocre.

The incorrect perception I had to overcome was that launching, with all the hard work it takes, is the end all, be all.  It’s not.  A “launch” just has to be a working product normal people can pay to use.  Like any web based, or self-updating desktop software, you can iterate well after version 1.

I’ve constantly had to remind myself of this as I document & wireframe functionality for both applications.  I get really disheartened when I recognize a Persona goal isn’t met, implement it on paper or the wireframes, and recognize the breadth of work I’m creating for my team.  The fun challenge I’ve found is figuring out how much I can take away, yet still launch.  The key point here is “take away” merely means tossed in the Backlog.  Good, valid idea, documented, but not making the 1.0 launch cut.

I don’t have to feel bad at all, in fact, I should feel good twice over.  First, because I’ve significantly reduced scope, and thus increased our chances of successfully launching; and second, I’ve done my part and documented the valid feature, and stored it in it’s appropriate place.

Painful process, but I seem to be getting better at it.  I can’t imagine building the Google.com homepage.

Projects Backlog

I do a lot. I’m busy.  I work a lot.  Thus, prioritizing my time in helping with these projects actually creates a “Project Backlog” in my real life… one that I am not following very well.  I can only do so much in a day, and if I don’t prioritize my tasks into a linear list, nothing will get done.  So far, I’ve tried 3 day sprints where I focus on 1 project for 3 days, and then hop back to the other.

Some days, that doesn’t work, and I get confused on which one was I was working on.  At the very least, I at least try to do my “5 minutes a day” rule: spend at least 5 minutes a day working on the task.

While the ivory tower solution is to focus on 1 project first, and get it done, it doesn’t work like that because there are dependencies.  So, I’ve tried to balance it out by working on 1 project while the other is in a lull/waiting on someone else.  Sadly, it seems a Project Backlog doesn’t really work because I can’t freeze it like a Sprint Backlog, and there are too many dependencies out of my control.  I refuse to waste time, thus, I’ll just hop to some other project to keep productive.

Conculsions

If I had the choice, I’d probably just focus on project at a time.  However, this is way different than coding.  With coding, assuming I have a ton of user stories and design comps waiting for me, the onus is on me, and the time is full.  With designing & managing… sometimes I physically can’t do anything other than wait.  Also, some of the tasks I need to do are a lot shorter.  Writing a document takes 30 minutes vs. 4 hours to code a component.  Therefore, it’s way easier to shuffle a schedule around, and make it full of multiple projects vs. just 1.  While hard, I feel like I’m on the right track… I just need another 10 years of practice.

Bottom line, I’ve found the Backlog really helpful in both capturing all we want to do, and all that we don’t have time to do.  It shields my from my clients inadvertently sabotaging my team’s development on their project, while ensuring we capture what they need.  It ensures everyone knows what they need to do, are setup to succeed, and is trackable.  It kills scope creep dead, and helps me reduce software complexity.