What follows are a few suggestions for adopting enterprise agile development successfully.
The traditional functionally-organized engineering group won't work. Splitting up software development into program management, user experience, product management, development, quality engineering, and documentation is too restrictive. Instead, establish Centers of Excellence. Each Center should focus on a core function such as team leadership (e.g. Scrum Masters), product ownership, user experience, system architecture, information management, quality, publications, etc.
Form Special Interest Groups driven by the CoEs to define, implement and monitor new guidelines. Keep the guidelines minimalist and simple. Guide the teams. Don't legislate them.
Establish team-based metrics to track team (and workgroup) performance, not individual productivity. Be clear about individual roles and responsibilities.
Establish a common vocabulary and standard rules (such as the 'definition of done') to be used by every workgroup.
Automate as much as you can. a) Workgroups should have the option of using physical or electronic boards. However, those boards will have to be rolled-up into an overall project status board. The rollups will have to be electronic to promote transparency. b) Automated regression testing is a critical success factor. Don't skimp on it. c) Consider an internal social networking tool for information sharing such as Yammer or Salesforce.com's Chatter.
Conduct retrospectives at the workgroup level and among workgroups. Inter-group communication and software handoffs will likely need improvement.
Get professional help. Good training and coaching are invaluable. Don't try to do this alone. Select a few staff members to become internal coaches/mentors (a kind of train the trainer approach).
Focus attention on 2-3 workgroups and get them to high levels of excellence in advance of everyone else so they can be role models. You'll be tempted to treat all workgroups the same and attempt to synchronize them at the same competency level. That's unlikely to be successful. Workgroups will perform at different levels. Embrace it.
Expect and encourage mistakes, that's right, encourage mistakes. Being truly agile means making mistakes and learning from them.
Set target delivery dates and hold them firmly. Everyone needs to recognize that the company is serious about meeting dates. Just be sure to give the workgroups the flexibility they need to determine what to deliver by the due dates.
As someone who has watched a couple of companies struggle to understand how to make agile work these suggestions are fascinating. Personaly, I've felt enterprises don't put enough into CI/CD to allow Agile to succeed but he idea of CoE's takes that idea and applieas to to each discipline imo.
What I like about the CoE's is that while a traditional functionaly organized team won't work, there still are these problems that fall along one or more functional domains. Lets just take *testing* as one example. Testing isn't just one thing but a whole litany of things. Sure deveolpers can focus on Unit Test while the old QA hats can focus on Functional testing but what about Smoke Test or Performance test? They require a much more cross functional approach becausr they can be so many things and require system knowledge of the app and the infrastructure.
I can confess that I don't personaly appreciate the need to automate roll ups of an overall project status board I do think the idea of automating Testing is key but I'd expand that idea beyond just functional regression. As I said in my previous post, tool(s) are needed that everyone can use here. Collaboration on the writing of test and the ability to share or run the test of others is so foundational to overall collaboration and success. In a way, test one great way to ensure a *common understanding* of the application with executable specifications sitting on the top of that heap.
With a solid testing foundation you are also in a position to *expect and encourage mistakes*. Everybody makes mistake but nobody likes leaked defects.
In my spirit of top 10 list having 11 items on them, I'd add, at the #1 spot, *Define what Done means!* It's not enough to say Done means Delivered unless that criteria is applied to the end of the iteration and not the Delivery Date. To have to be done at the end of a sprint/iteration really forces your hand on a lot of the technical practices that really enable Agile to succeed.
In the spirit of end-of-year top 10 list I thought I'd try my hand at one of my one. Changing a culture is all about changing behaviors so here is my take on where to start and the baby steps down the road towards transformation.
Establish Release Authority - Sadly, this most fundemental of points still needs to be explained in many organizations. Even if you already have a Build System, it's important to remember why that's important as well. This idea I learned pretty early on from Anti-Patterns and Patterns in Software Configuration Management. If you still have developers building localy and emailing artifacts, then you are indeed starting from scratch. Release Authority is the most foundational of concepts upon which everything else is built.
Build Your Code with Every Commit - I'm avoiding saying CI here intentionaly since I'm trying to build in baby steps. Be it polling or triggers you need to know that code still, at least, compiles. Keeping the build *green* at this stage is an important cultural norm to establish. Once the build it broke, deal with it. Stop commiting until it is fixed or rolled out. Bring shame to anyone who commits broken code.
Unit Test - It is simply too easy to turn on automated unit testing to not be doing it. Be very clear about what is, and isn't, unit testing. The term is all-to-frequently missused. Always ask if unit testing is being done and if the answer is *yes* make them explain exactly what they mean by that. Too often it means a local build was done and they clicked a few things to test there functionality/widget/fix which is NOT unit testing. Unit testing is one more small bit of assurance and not a silver bullet by any means. It is also another level of pre-commit validation and as such folks whose commits break the build should be publicaly embarrased and ridiculed ;-)
Scan Your Code - Much like unit testing it is simply too easy to do this these days not to be doing it. The richness of these tools vary by language but find what your language offers and leverage it. Static and Dynamic analysis, like unit testing, is not a silver bullet but then quality is like security and needs to happen at every step along the way (read Caper Jones if your not familiar with this idea). Java shops should look into Sonar if you haven't heard of it. These tools are a lot like the cockpits of an airplane, they wont fly the plane for you but they provide lots of feedback to help you make informed decisions.
Get Control of your BOM - If you cannot easily show your Bill-of-Materials you're probably not in control of your product. Putting third party liberaries into you SCC tools doesn't count either since you can't prove what is actualy used or not or where they came from or if they've been tampered with. There isn't really just one thing to do to get control of this so the next couple of items on the list will try to identify the 'How'.
Setup a Binary Repository - I can still remember a time when not everyone was using SCC but it didn't take too much convincing to get everyone on board. Today, binary repositories occupy that distinction. Checking your binaries back into your SCC tool is not the answer either. Tools like Artifactory and Nexus do the job well and can be had for free.
Manage your Dependencies at Build Time - Maven paved the way here but there are several alternatives these days. If your an Ant shop, look at Gradle as the way forward. I'm still a big fan of Maven but Buildr has got my attention as well. Either way modern build tools can help you manage your dependencies with the Binary Repository. At this point we have a basic CI system.
Automate Deplyment to Dev - Much like #1 was foundational to every else after it this item is the foundation upon which we can build a Continuous Deployment/Delivery system. By focusing on one environment and driving toward zero-touch, self servicable deployments we can pave the way for everything to follow. It's a huge task so stay focused on Dev. Up until now we could have done most everything for free but this is where we'll likely need to spend some money. With that in mind get in touch with your companies budget cycle and give yourself lots of time to make the case and garner support. Much like getting control of the BOM was a huge task, this one is even bigger, much more complex and varried. To that end the next couple of items will shed some light on the 'How'.
Think About the Functional Decomposition of your App - Continuous Delivery taught me that we can functionaly decompose an into 4 pieces: Code, Configuration, Data, and Environment. The first 7 items in this list focused on the code and now that we want to deploy it's time to think about the rest. A deployment pipline tool like UrbanDeploy or DeployIt can help a lot with middle tier configuration and even DB changes.
Think About How Every Can Collaborate on Testing - Automated testing has a long and not so rich history in software development. Virtualy any enterprise that has tried will tell you that it doesn't work, I'm here to tell you they were doing it wrong! Tools like QTP and testing through the UI are simply the wrong aproach. What's really needed is a tool(s) that everyone can use so that we can think about the life-cycle of a test. How do new test get written? and more importantly, how are they shared? How does a defect become a test become a regression test? We also need to think about more than just functional testing. We need to consider Smoke Test and Performance Test and how we bake these into that automated deployment. We need to think about which test get run when and how long they take.. I'm going to read Agile Testing in the hopes that it can help me here as this is precisely where I am today.
Specification by Example - Ok, I said 10 and really this is a part of #10 but worth it's own entry. Specification by Example is quite possibly the most important advancement in Software Engineering since OO was introduced, at least in my opinion anyway. And while I'm no fan of Silver Bullets this may well come the closest to being one. If 2012 is the year of breaking down silo's then Spec by Example is one example of how to do that when the Business and Developers learn to write the spec together, derive scope from that spec and ultimately turn it into an executable scenario/test.
This deck has a couple of visuals that are keeprs! What's more, I really think this style of development / testing is the most important advance in software engineering in a very long time. While I've never fully bought into Uncle Bob Martin style TDD I would however advocate for 100% coverage of User Stories with Acceptance test. When it comes to Unit test I do like non-functional quality measurements to be baked into the business requirements from the start. For legacy apps I'd target ~80% coverage for the most complex and/or the most used pieces of the code base.
I'm usualy not big on semantics but I do think calling this style of development, Business Driven is both the smartest and most accurate description of the process. In the end it is is always the *Business* you have to sell too, so why not give them what they want?! It drags product owners right into the actual development process since they have to write acceptance test. I'm also betting that once they get a taste of that, they'll be hooked and wont be able to stop writing test.
I also like the idea of leveraging the idea that Business and IT *pair program* these test to deliver both business facing and technology facing test. Really pause for a moment and think about that, the Business and IT pair programing, using a Domain Specific Language in a way that ensures they reach a mutual understanding of what is expected! How does it get any beter than that?!
Udate: 2 Jan 2012
Having recently read Specification by Example I have been convinced that the name is important semantics and all
Steering a Super Tanker is an excellent presentation that shows some innovative way to identify and attack technical debt. At the heart of this presentation is the notion of identifying and remediating modules with high complexity per method, an approach I too would advocate. However I find it curios that the motion chart axis are set to complexity/method in the Y and LOC in the X with color and size set to complexity/method and overall complexity! The beauty of the motion chart is it's 4 axis representation so I find the size and color setting to be redundant. It's no coincidence that the color exactly correlates to the Y axis while there is also a strong correlation between overall complexity and LOC. It's not until the Gaming the Metrics section that the author comes close to a setup I use everyday. I find that setting the Y axis to Coverage, X to rules compliance with Color set to Complexity per method and size to LOC provides an excellent overall view of the modules. With this arrangement we can see zero-test modules and identify any high complexity items as risk. So long as our highly complex items also have high coverage then we might not have to panic so much.
The other really great thing about this view and the Motion Chart in general is the ability to spot things over time. At my last job where I was monitoring millions of lines of code accross 50+ projects I would periodicaly view the motion chart, in motion. This video playback representation of the data over the previous three months frequently allowed me to spot interesting events within projects. One great example that I love to cite was when I witnessed a sharp increase in coverage on a couple of the hundreds of modules under inspection. First one, then a second and third module shot up the chart (coverage) and then drifted to the right (rule compliance). All three modules where a part of the same project and prompted me to reach out to the project owners to commend their efforts and learn how it come to be. What I learned was the team had installed a lava lamp to indicate broken builds and the business owners had come to be aware of the lamp upon seeing it lit up. The short story is this lamp then led to a discussion as to why the build was broken and ideas about how to improve. The developers had felt like they weren't funded to write to unit test but explained how they could have helped identify issues in local builds before the code was committed. So, the business added a Unit Test coverage target, along with a rules compliance target, to thei non-functional requirements thus authorizing the developers to spend time on these task. Within 2 weeks the three modules had 80%+ coverage and improved their rules compliance by 15-20%!
While the Motion Chart is a great visualization I'd also suggest keeping a close eye on Clouds->Top Risk and Hotspots. Clouds offers a much more granular view and can spot complex/low coverage packages that can be hidden in high LOC components. Hotspots provides a no-nonsense, actionable view of potential areas to dive in one.
In general, the biggest issue I battle with Sonar implimentations is that people really want to be *told* what to fix. It takes time to get folks used to Sonar reporting and to establish a culture that knows how to drill in for themselves based on the issues at hand. Sonar provides so much data it can be overwhelming at first. I've found that focusing on Coverage in the Most Complex or Most Used modules/packages is a good place to start for legacy apps.
Greenfield apps should establish non-functional requirements for Rules Compliance and Coverage and consider using the SQALE model to focus efforts by life-cycle. Use sonar after each sprint/iteration and/or release to continualy monitor, talk about and remediate issues as they appear.
An interesting looking emerging Software Quality Framework. Mapped right onto the SDLC it seems to combine a lot of ideas that have come before it. Sonar had already been reporting on Static and Dynamic analysis results in terms of things like reliability, portability..., they even had a technical debt plugin SQALE seems to use the technical debt metaphor but in a very practical way. You decide your Quality thresholds and SQALE would tell you, in terms of amount of remediation (TD?) how far from your target you are. SQALE does introduce some interesting data visualizations that makes it easy for programmer and App owners to quickly see how they are doing and make decisions about where to direct your resources.
The layered approach to the disciplines combined with the cumulative nature of the total index and it seems to re-enforce the idea to start with unit testing and then write good code as a means to improving the overall quality. No funny weighting, just the aggregate TD.
The more I think about it, the more I think this approach is diametrically opposed to the current Sonar dashboard. In Sonar, you want to get your compliance percentages closer to 100 while it prioritizes the rule violations by severity. The natural response is to work on any Blocker first, regardless of it's classification, Maintainability or Changeability for instance.
In the SQALE model, it implores you to get a testing foundation first, both unit and functional, to keep your numbers low. Their spider graph puts a green bullseye in the middle with a red outer ring. Instead of trying to get your graph out towards 100 you want to drive it towards 0. It also shows the *stated* goal for each axis or the amount of acceptable technical debt for each *phase*. This approach seems much more in line with agile methodologies where as Sonar's makes a better fit for Legacy applications. New agile apps can avoid ever creating a mountain of technical while legacy apps surely have a mountain to chip away at.
More than anything else, I see the SQALE model as a mechanism to drive a Software Quality initiative within the Enterprise. Every aspect of it appeals to the sensabilities of corporate culture. A well defined defined model that lets you pick your level of involvement combined with easy-to-understand metrics to measure results with.
As Figure 1 demonstrates, a Java file with Cyclomatic complexity of 38 has a probability of 50% to be error-prone. If you do not stop it prior to deployment through technical debt criteria, it is likely to affect your customers and play havoc with your deployment quite a few times in the future. The fact that it did not do so during the first hour of deployment does not guarantee that such a file will be “well-behaved” in the future.
I am going to go back through my *work* related post from Lasterday and bring them over here, revisiting them as I do so.
I remember this chart in particular really grabbing me, the idea that a 50% probability of a defect could be predicited from nothing more than complexity. Could we start to produce *potential defect rates* a la Casper Jones and function points? Even if it has decent testing at say the Unit and Functional levels? Is every 80 points a defect or more?
The idea of tying TD criteria to release criteria is an interesting one though I'd prefer to have *business goals*. If the *business* is the driver then there is no question but if the dev team set's these *technical* thresholds, then how do you rationalize a delay back to the business??
What would be some reasonable goals? Minimum 50% unit test coverage? No more than $2 TD/LOC? Does something like SQALE make the most sense as a way to define and track quality goals?
Welcome to my new personal branding site, onCommit. Named after SCC style *hooks* that can trigger builds and everything else we can automate after code is checked in. I will try and bring over stuff from my Lasterday site but this site will allow me to better channel my proffessional interest separate from my personal ones. My facebook friends wont have to look at all of my geeky post and my LinkedIn contacts don't have to see my kids recital ;-)
There is an companion Twitter account @onCommit. Stay tuned.
