My recent road trip was a great reminder how quality is durable.  As I passed through familiar territory, it was interesting to see how many building and places stood the test of time.  Whether it was a business or a building, it was quality that survived in the long run.  Some of the restaurants I remembered were gone.  Every restaurant I remembered that was high quality, was still around.

Competing on Price Fails in the Long Run
Competing on price failed, time and again.  There was no customer loyalty when it was the price play.  There was no compelling distinction beyond price.  Chasing the price play, meant getting priced out of market by somebody better or cheaper or you name it.  There are only so many corners you can cut before your value is insignificant.  On the other hand, the quality play is focused on differentiation and distinction in terms of value.  In a globabl market, where cycles of change are faster, competing on price is a game I just don’t want to play in.

Do You Stand Behind Your Work?
One of my most important tests, and it’s a simple gut check, is, do you stand behind your work?  It’s a cutting question.  When your results are something you’re proud of, and quality is your game, and continuous improvement is your way, and excellence is your bar … you set yourself up for success.  When you can put yourself into your work, the journey becomes as enjoyable, if not more so, than the destination.

In times of change and uncertainty, driving from quality is a guiding principle that helps us find our path.

Photo by Cornell University Library.

On the Microsoft patterns & practices team, we use Vision / Scope as a key milestone.  It’s where we frame the problem, identify the business opportunity, and paint a vision of the solution.  It’s a forcing function to get clarity on the customer, their scenarios, and our scope for the project.  We generally use a “fix time, flex scope” pattern, so this means having a candidate backlog that we prioritize with customers.

On the execution side, we expect to know the team, key partners, the budget, the schedule, and the deliverables.  We also need to know the risks and their mitigations.  At the Vision / Scope, the real key is first selling people on the vision, and then selling them on the execution.  It’s basically about answering, “why?” should we go do this, and “why now?.”  This can be either about reducing pain or exploiting an opportunity.  It’s also about answering these questions in the context of trade-offs.  When you can tell a compelling story from problem to solution, and how you’ll get their incrementally with a team people trust, you dramatically increase your odds of getting a “Go” decision, and the support you need.

Vision / Scope Baseline
This is my rough sketch of the key pieces I need in my Vision / Scope presentations for success:

Vision / Scope Examples
Here are some examples of various Vision / Scope slides from over the years:

My Related Posts

• Vision Scope Template
• Lessons Learned in patterns & practices
• Framing the Landscape

Here is a draft of our Cloud Security Frame as part of our early exploration work for our patterns & practices Cloud Security Project.  It’s a lens for looking at Cloud Security.  The frame is simply a collection of Hot Spots.  Each Hot Spot represents an actionable category for information.  Using Hot Spots, you can quickly find pain and opportunities, or key decision points.  It helps us organize principles, patterns, and practices by relevancy.  For example, in this case, we use the Cloud Security Frame to organize threats, attacks, vulnerabilities and countermeasures.

Hot Spots

This is our current set of Hot Spots for our Cloud Security Frame:.

• Auditing and Logging
• Authentication
• Authorization
• Communication
• Configuration Management
• Cryptography
• Exception Management
• Sensitive Data
• Session Management
• Validation

Cloud Security Frame
Here is our draft of the Cloud Security Frame with a description of each Hot Spot category:

Threats, Attacks, Vulnerabilities and Countermeasures
Here is our working draft of our threats, attacks, vulnerabilities and countermeasures organized by our Cloud Security Frame:

How do you convince a team of venture capitalists to bet on you?  There’s a lot of ninja techniques but here I’ll share the fundamentals.

Vision and Scope
At patterns & practices, we use Vision Scope milestones to sell management on how we’ll change the world.  Knowing the vision and scope for a project is actually pretty key.  The vision will motivate you and your team in the darkest of times.  It gets you back on your horse when you get knocked off.  The scope is important because it’s where you’ll usually have to manage the most expectations of what you will and won’t do.

Thinking in Terms of Venture Capitalists
When I do a vision scope, I think of the management team as the venture capitalists (a tip from a friend.)  This helps me get in the right mindset.  I have to convince them that I have the right problem, the right solution, the right customers, the right impact, the right team, the right cost and the right time-frame.  Hmmmm … I guess there’s a lot to get right.  A template helps.  The right slide template helps because it forces you to answer some important questions.

Template for Vision Scope
Here’s the template I used from my last vision scope meeting:

Vision / Scope

• Agenda
• Problem
• Vision
• Approach
• Prioritized Tests for Success
• Scope
• Key Activities
• Deliverables

Execution:

• Execution
• Team
• Budget
• Schedule
• Risks
• Asks
• Go/No Go

It’s implicitly organized by problem, solution, deliverables and execution.  While the slides are important, I found that the real success in vision scope isn’t the particular slides.  It’s buy in to the vision, rapport in the meeting, and trust in the team to do the job.

What works for you?

Photo by Robert Couse-Baker.

Editor’s note: This is a guest post from Mike de Libero.  Mike has been doing software development for more than 9 years in a variety of settings.  He’s worked as a freelance developer.  He’s also worked on a small team of developers maintaining 30+ programs at one time.  He’s even worked as a security tester on the Microsoft Office team.

I first met Mike through Mark Curphey.  Software security is a small world.  The funny thing about many of the people I meet in software security is that they 1) tend to break things to make things better, 2) like to help, and 3) focus on improvement.  The great thing about Mike is that he’s got a passion for development, and he’s more focused on principles, patterns, and practices, than on a particular technology.  Here are Mike’s top lessons learned in software development …

Top 10 Lessons in Software Development

Here is a summary of my top lessons in software development:

• Lesson 1. All software is flawed.
• Lesson 2. Check-in often.
• Lesson 3. Tests, gotta love them.
• Lesson 4. Refactor, check-in and repeat.
• Lesson 5. Coding is easy, humans are tough.
• Lesson 6. The more eyes on your code the better.
• Lesson 7. Keep learning and improving.
• Lesson 8. Simple is beautiful.
• Lesson 9. Learn software development not coding.
• Lesson 10. Think about your audience.

Lesson 1. All software is flawed.
Anyone who has written a software program larger than “hello world” knows that there will be bugs.  That is just a fact of software development.  These flaws occur because the way a piece of software is written is a reflection of what the developer’s though processes are and what challenges he or she is trying to solve.  Because human thoughts are not logically perfect all of the time, errors will occur.  Also, software development is always a trade-off between time/money and features leading to items left partially coded or rushed through.  Which leads us to the next lesson…

Lesson 2. Check-in often.
Everyone is using source control, right?  If you are not, start now!  When developing software or doing heavy refactoring, source control is your friend.  The more often you check-in a usable piece of code the easier it is to rollback if you completely screw something up.  On teams that require a code review before check-in or they freeze check-ins setup a private source control server it is so quick and easy.  I always think of source control as an undo button and it partially frees the developer from the fear of screwing up publicly.  If you use source control and unit-tests almost all fear just goes away.

Lesson 3. Tests, gotta love them.
Ahh unit tests… Everyone says you have to use them and they are the best thing since sliced bread.  I happen to agree for the most part.  When doing greenfield development I make sure unit tests are always written and used.  However the idea of unit tests as a part of the normal development cycle has only become semi-common in the last five years and good software was built long before then.  Keeping a list of common tests that should be ran outside of an IDE is also a great thing to have.  I think the greatest advantage of unit tests is that as long as they are quick to run it allows for a quick sanity check for the developer.  If source control is the development undo button then unit-tests are the babysitter that yells at you for doing something you wouldn’t do if your parents were around.

Lesson 4. Refactor, check-in and repeat.
No piece of code is perfect but it can hopefully become better (and yes it could get worse) by going back over and asking the questions “what can I do to make this shorter, easier to understand, etc…”  People do this all the time when writing papers but it doesn’t happen often when writing code.  After each interval, check-in the code in case you go too far and removed some needed piece of code.  Depending on the size of code being refactored there might be many iterations.

Lesson 5. Coding is easy, humans are tough.
Don’t get me wrong, there are some hard problems in coding but they are not as hard as figuring out what our fellow beings want out of a piece of software.  Humans tend to be fickle and contradict what they say.  On top of that it is very hard to communicate clearly and a barrier exists between “geek-speak” and normal vocabulary.  It becomes extremely difficult to figure out what users are asking for.

Lesson 6. The more eyes on your code the better.
Whenever I go into a new code base or one I haven’t been into for a few weeks I always spend a few minutes browsing around looking for things to improve.  When I spot something that was a bad implementation or just a bug I shoot an email over to the developer and let them know how it could be improved (I also change the implementation to make it better).  I ask for and expect the same thing out of any developer I work with.  Why?  Because it keeps us honest and teaches us ways to make our programs better.  Sure, this might not be a sit-down code review but I find this to work fairly well at least for smaller teams.  The more formal code reviews are nice to and have similar goals: higher quality code, bugs found before QA gets it and information transfer.  I think it all depends on the environment you are in.

Lesson 7. Keep learning and improving.
This lesson is pretty obvious but it has to be said.  If you don’t learn and/or keep improving you risk becoming a fez which I doubt anyone wants.  My usual metric is:

• 1)    What new language / technology / technique did I learn in the past month?
• 2)    When looking at my old code can I easily find better ways to do things?

I think the second metric is very important.  If you can’t think of ways to improve the code - even if it is not feasible in the current code base – then you should be concerned as that is one sign you are not growing.

Lesson 8. Simple is beautiful.
The acronym KISS is awesome and I try to follow that when developing software since I also believe in the idea that as software grows it becomes more complex.  Whenever I have to fix an issue or write code I always ask myself “can it be any simpler?”  Simplicity has many benefits and not just from a development perspective some of them are:

• Code is easier to understand
• Maintenance tends to be easier
• Simple UIs tend to make programs easier to use

Lesson 9. Learn software development not coding.
Personally I make a distinction between coding and actual software development.  I think there are far too many people who focus on just the coding portion and not the bigger picture.  Many people can write code but it seems fewer people can design a system, test a system, write the code, document the architecture, talk to users to figure out requirements, create semi-accurate estimates, help other team members and when designing a user interface know the basics of user interaction.  There are things all developers should know about coding as well but I feel improving your coding chops is pretty easy and is done as you develop software.  Learning and improving in regards to software development is not necessary for one to hold done a job as a programmer.

Lesson 10. Think about your audience.
When reading this point did you immediately jump to the users of the program for which it is being created?  If you did you forgot a few other audiences :).  Whenever you code I find that there are at least 4 audiences: the compiler, other programmers / your future self, attackers/malicious users and then the users of the program.  All of these audiences require different things and the easiest audience to please is the compiler.  The other audiences take a bit more work while creating software.  For example the attacker audience we really want to piss off instead of please and pissing off an attacker is fairly easy by just not trusting input and properly encoding output (note: this won’t protect you from everything in the attacker arsenal but it will take care of a huge amount).  The developer audience is fairly tough as we tend to think all other code is stupid or at least have an opinion about it, this stems from the differences in how each person thinks (at least that is my opinion on it).  Commenting business logic, writing clean and clear code and keeping it simple usually helps the development audience.  For the actual users of the program they are an interesting group.  There are many books on usability and design so I am just going to suggest you pick-up a few good books on that matter (if you need any suggestions feel free to get in touch with me).

Editor’s note: This is a guest post from James Waletzky. James is a Development Lead at Microsoft and he maintains a blog about software engineering at http://blogs.msdn.com/progressive_development. James has shipped quite a few products and has worked on the Microsoft Engineering Excellence team, where he taught developers about agile and other software engineering practices and consulted with internal product groups to improve their engineering practices.

When J.D. asked me to share my thoughts on some top software development lessons I’ve learned throughout my time as a developer, I jumped at the chance. I have had successes and failures, and consulted with teams that share the same. Below is my list of 10 lessons I have learned through hard experience. This list is by no means definitive, but is gleaned from years of development experience.
Without further ado…
Ten Software Development Lessons

• Lesson 1.    Keep it simple.
• Lesson 2.    Define ‘done’.
• Lesson 3.    Deliver incrementally and iteratively.
• Lesson 4.    Split scenarios into vertical slices.
• Lesson 5.    Continuously improve.
• Lesson 6.    Unit testing is the #1 quality practice.
• Lesson 7.    Don’t waste your time.
• Lesson 8.    Features are not the most important thing.
• Lesson 9.    Never trust anyone.
• Lesson 10.    Reviews without preparation are useless.

Lesson 1.   Keep it simple.
I lost count of the number of over-engineered, over-complicated designs that I have seen throughout the past few years.  Software developers are ever in search of the most elegant solution to a problem. Guess what? Complexity causes problems - like prohibiting understanding of the design and code, causing maintainability issues, increasing the likelihood of bugs, generating bloated code, and often causing difficulty in testing. From the age old adage:
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." — Antoine de Saint Exupéry
Build in extensibility only when you need it. Accommodate change in your designs - don’t anticipate it. Keep class definitions small. Follow the Rule of Seven (i.e. 7 +/- 2 rule) when grouping concepts like methods on a class. Measure code complexity and refactor as necessary. There are many other strategies for keeping design and code simple. Use them.

Lesson 2. Define ‘done’.
Have you ever asked a developer how far along they are in their feature development? I am willing to bet that the most typical answer is 90%. Then next week you ask the same question and get the same answer. When they are eventually 100% ‘done’, do you know exactly what that 100% entails from the quality side? How exactly would you define "code complete"? I bet your answer would be different than mine, and different from J.D.’s.
It is important to have a clear, agreed-upon definition of ‘done’ at many different levels, including individual check-ins, component development, feature development, short iterations, milestones, and finally, release. On my team, code is ready for check-in when all unit tests pass, unit tests achieve 80%+ code coverage, code has been reviewed, design docs are in place, the code is free of memory leaks, and several other criteria. Our check-in checklist is arguably our most important tool. In fact, checklists are a great way to track these definitions. The meaning of ‘done’ should become commonplace and a part of your team’s vocabulary. Write it down so there is no confusion.

Lesson 3.    Deliver incrementally and iteratively.
Unfortunately, my crystal ball is in the shop being repaired. Until I get it back, it is hard to predict the future and derive a detailed plan that I am sure will hold true for the development of many features . In the absence of that crystal ball, delivering software in a piece-wise fashion helps achieve success. Break your scenarios into pieces and deliver small chunks in short iterations of 2-4 weeks in length. Get feedback early and often. Fold the feedback into the next iteration and incrementally build upon the results of the previous iteration, refactoring as needed to keep the design clean. You will end up with a better result than if you swim down the river and fly over the waterfall.

Lesson 4.    Split scenarios into vertical slices.
Assuming you are practicing scenario-based development, which could also easily make this list, to help deliver real business value in short iterations, it is important to break functionality into chunks. One method of chunking, assuming a typical architecture of data, logic and presentation layers, is to deliver the lowest level (data) followed by the middle layer (logic) followed by the user interface (presentation). The user does not care about the data layer and you miss the chance to gain valuable feedback if you deliver in this first. Instead, break things up vertically - deliver an end-to-end scenario with just enough data, logic and UI to support the scenario. The feedback you receive will factor into future scenarios and you adjust the design as you go. Additionally, you never write code that is not used, and adhere to the principle of YAGNI, or "You Ain’t Gonna Need It".

Lesson 5.    Continuously improve.
Tightly coupled with delivering software in an iterative fashion is the idea of continuous improvement, often called "Kaizen". Nothing is ever good enough - at least, that is the way you should think. Work to constantly improve your processes, the way the team works together, your tools, and anything else that contributes to your software development. Step back early and often and do a retrospective on the previous iteration, feature delivery, or even past few days of work. What went well? Continue to do those things. What didn’t go so well? Get beyond the symptom to the root cause of why there were issues and come up with actionable ways to fix them. Put those actions into practice in your next iteration.  Always strive to become a high performing team with the world’s best product.

Lesson 6.    Unit testing is the #1 quality practice.
I often get asked the following question: if I could change one thing about software development to encourage improved early-development cycle quality, what would it be? Easy - improved unit testing. Historically at many companies, developers would write the code, run the "happy path" through the debugger, and throw the code over the wall to the test team for validation. Quality would be "tested in". On more recent teams we have been doing much more unit testing  using code coverage as a feedback mechanism and quality has risen substantially. Additionally, unit tests give you the confidence to refactor your code at any moment in time leading to cleaner designs and more maintainable code. The icing on the cake is having the tests run as part of a daily build, so you always have quick feedback as to whether functionality is broken. The disadvantages are that unit tests take time to write and you add 50%+ more code to your product, but the investment is worth it.

Lesson 7.    Don’t waste your time.
The agile development manifesto values working software over comprehensive documentation. This guideline has proven valuable. Several projects I have experienced went overboard on plans, requirements specifications, designs, test plans, process documentation, release plans, etc. Don’t get me wrong - there is value in these documentation artifacts. The key is to do "just enough". Know the audience for your documentation and do the minimum amount to meet their needs. Any more than that is waste. Every activity in the development cycle should add value to the business, product or end user. Spend your time on activities that count.

Lesson 8.    Features are not the most important thing.
Yes, you heard correct - features are not the most important thing. Of course, if you are writing a v1 product, features are pretty important. However, in today’s software market, quality and fit and finish are just as important as features. The software needs to "just work". Quality attributes such as performance and reliability are huge satisfiers and are expected by customers. Fit and finish, or polish, on a product set it apart from competitors. A good example of fit and finish that could have been cut from the Apple development cycle are the rubber band effects on the list control on the iPhone. When I bought my iPod Touch I flicked that thing over and over because I thought the effect had a significant cool factor. It delighted me. I fell in love with the device. Of course, polish goes hand-in-hand with features and quality attributes - the device must do what I want it to do and not crash while doing it. The point, however, is that fit and finish is very important in today’s software world and should not be neglected.

Lesson 9.    Never trust anyone.
Ok, not literally. I am not talking about trusting your teammates - that is extremely important, and if you ask Stephen Covey, "trust is the life-blood of an organization". Here I am talking about trusting calling code outside of your boundary (e.g. any public method). I have seen more security vulnerabilities than I can count resulting from a failure to validate input parameters. I have seen more bugs than I count that could have been prevented by programming defensively. Use assertions liberally in your code to validate internal state.  Use trace statements strategically to dump out debugging state. Assume that some client with bad intentions will call into your code and handle all the error cases gracefully. One piece of advice that a good friend of mine and contributor to this blog, Corey Ladas, once told me: "write code as if the debugger doesn’t exist". That slight switch in mindset, coupled with a focus on unit tests, will make you a much more efficient developer reducing your time in the debugger, where you are generally least efficient.

Lesson 10.    Reviews without preparation are useless.
If you ever get invited to a spec review or code review without having seen the document or code prior to the review, just say "no". In this case, you are about to violate lesson #7 and waste your time as well as everyone else’s. Code reviews are a valuable quality control technique that every software development organization should practice. The key to a successful review is receiving the artifact up-front and having that focused alone time to prepare and find issues. The meeting is simply used to gather the feedback and learn from one another. The meeting is not used to find more issues. It pains me to see many hours wasted in useless reviews. Don’t be a victim.
The above list of lessons learned in software development is the tip of the iceberg. There are many more lessons that could be added to this list to make us all more successful. I would love to learn from all of you as well, and hear about your top lessons learned. Care to share?

Additional Resources
There are many resources for each of the lessons in the above list. For a gateway to many good resources, see the Progressive Development blog listed below, as well as many of the other postings on this site.

• Progressive Development (James Waletzky’s blog)
• Lean Software Engineering (Blog)

Editor’s note: This is a guest post on software lessons learned from Alok Srivastava.  Alok is a solution architect at Microsoft with more than 17 years of industry experience.  He specializes in software architecture, large-scale systems, and distributed computing.  Alok has filed for a dozen patents, published several papers, and presents his ideas at many conferences. He has a wealth of experience across large scale projects, database extensibility, multimedia and content management in RDBMS, Web services, portal technologies, and content distribution networks.  In this post, Alok shares his lessons learned …

These are my top lessons learned drawing from my years of software experience.  I am sharing them with you here.

Summary of Lessons
Here is an index of the lessons that follow:

• Lesson 1. Software development is a team sport.
• Lesson 2. More lines-of-code does not mean better software.
• Lesson 3. The Cloud is an inflection point.
• Lesson 4. Scalability, performance and diagnostic ability are better achieved at design time.
• Lesson 5. User experience and user expectation change continuously that is why UI projects are never done.
• Lesson 6. Software maintainability is a key to longer life for any software.
• Lesson 7. Development process should help development produce good quality software, if it comes in your way change it.
• Lesson 8. Take agility with a grain of salt; result –oriented software development is what agility should help you gain.
• Lesson 9. A great software engineer never stops working.
• Lesson 10. Know the keys to writing great software; magic isn’t one of them.

Lesson 1. Software development is a team sport.
Complexity of software systems has grown over past several years. If a software solution has to reach a customer, they need a lot more than just code. They need to install, configure, administer and monitor what they are getting. Developers may need to program with the platform that you are providing. They may also need to bill for usage, measure performance, increase load and add users. At the same time they need to be able to learn, get help, and localize the software for their audience. If the software doesn’t work right, they need to be able to tell you what is not working right. The list goes on and on. Just the software that solves a specific problem can not cover all of this. Developing an industry strength, enterprise class software isn’t something one person can even comprehend. You need a team of folks who are good in their areas of responsibility. This team includes, program managers, development leads and developers, quality team, configuration and install team, management tools team, documentation and release team and of-course evangelists, trainers, support professionals and consultants.
When I started to think about bringing my ideas to life, I could prototype and come with demonstration quite easily without depending on anyone else but turning those ideas to product was a whole different story. I needed a virtual-team that could help me with everything I needed to get the product to price list. Even while working on a startup, a team was needed to get the concept to customers.

Lesson 2. More lines-of-code does not mean better software.
For many years, I have been hearing that the larger lines of code (LOC) somehow indicate that it is better and complex software. I have used that metric in my conversations as well but I have not been convinced that that is actually true. Some of the code that has lived for many years has grown in size as additional functionality was added but one has to understand that back then there was no managed environment and languages such as C# or Java. Operating system may not have helped you much therefore there was a good reason to write all you needed from ground up and that made the code grow fast. Over time even these systems (Windows for example) also have come to realization that they can do better with fewer lines of code. When it comes to managed code environment (like Java and C#) one can do a lot with very few lines of code. In fact, fewer lines of code mean that you are using the facilities that the managed environment provides in the way they were meant to be used. Any time my software team came to me to tell me that they have written a hundred thousand lines of managed code, I had to make them pause and review parts of the code to make sure they were not trying to re-invent the wheel. Given the level of functionality that is available from managed environment, toolkits and operating environment, the LOC measure for code quality complexity should now be outdated and better measures should be developed for the same.

Lesson 3. The cloud is an inflection point.
What we know as cloud and cloud computing started many years ago when Internet started to form. While the most commercially viable applications focused primarily on web site and e-commerce in 1997-1998 early ideas of using Internet as a network that separates users from servers were already taking shape. As usual, it has taken a while for technology to make that scenario viable. Virtualization has also followed the trend to make it possible for cloud to finally form. At the same time, managed environments and Internet based application delivery has eased the fear of losing control if you did not see the hardware running your app underneath your desk. It has taken several computing and IT areas to mature before cloud can be realized. Now that the cloud is here, we are nearing closer to utility computing. If my vision serves me well, we are not too far away from a time when a consumer will be able to create their own way of doing business on the Internet by picking the services that are available and are willing to compete for my business. We are still in learning mode though. Many corporations haven’t yet figured out what the cloud is and what it could mean for their business (or their competitor’s business). Add social interactions on the Internet to the mix and you can see the picture better. Cloud should not be very confusing but when it comes to defining what a cloud is, many people have different perspectives. The way I like to understand cloud is that cloud is a method of service delivery. It defines application/service deployment and access patterns and it is built on services on the Internet (be it platform as a service or software as a service). If cloud is the way we started, the picture would have been simpler and transition much easier. Unfortunately we have many years of legacy dealing with client-server and n-tier applications and it will take time to comfort all weary souls that cloud is all new beast that they need to deal with. Say whatever you like, define it the way you want but the cloud computing is going to have a major impact on our industry and will change the way software business is conducted.

Lesson 4. Scalability, performance and diagnostic ability are better achieved at design time.
This is something I have learned over time and having learned my lessons, the first thing I try to tell anyone writing software is to think hard, design more, analyze as much as you can before the coding begins. When you are first developing application functionality is always on the top of your mind and everything else that software needs takes back seat. I can understand why a software engineer wants to implement functionality first; they get to see the outcome of their hard work. They always say, let’s get it working first and we will deal with the rest of it later. I wish I could give them the budget to build the software from idea to customer and over the life of the software, they will see what I see most of the time. These are the primary reasons why almost all software start ups have to go through a re-architecture cycle before they can have a sustainable software system that works well as their company grows. While I understand that it is not practical to worry about performance and scale when you have to have something in market next month. Many times that is not what pushes the thinking around performance and scale (diagnostic ability is implied throughout our conversation) simply because we don’t want to deal with this. If one could see the overall cost (translate to time spent by many people and re-architecture), they will not ignore these. I would rather extend the design and architecture phase a bit longer in order to save a lot of time and headache later. During design time if your desired parameters for performance scale and diagnostic ability were defined, your design will have to meet those criteria before being accepted. During design time, though experiments and prototyping can help open up the system for large scale and better performance later. If you have thought about it while designing your system (and software) you would know what the impact of scale would be, where your system is likely to become resource constraint and what you would have to do to allow the scale and better the performance. If nothing else you will be able to pre-define the use criteria for your system in order to not fail or get customers in trouble and you will have your requirements for the next release. You may get a chance to put in place low level instrumentation that will help you achieve your performance, scale and diagnostic ability goals during next development cycle even if you did not have time to do it now.

Lesson 5. User experience and user expectation change continuously that is why UI projects are never done.
I have been involved in many UI projects to experience this first hand. The user experience pendulum swings from rich and responsive interface to interface available everywhere. Something that gets the job done or something that keeps people engaged and involved is also a topic of discussion when you are doing a UI project. Sometimes you will also hear productivity argument when it comes to UI. Usability, compliance, localization ability, customizability and personalization are all the terms that get considered when UI project is at hand. First thing that I have learned over time is that no matter how good a UI you think you have there will be some people who will hate that little button. What I am trying to say is that you can never make everyone happy with whatever UI you give them. And that’s not all, people will change over time. If your application is going to be in use for many years, be assured that even those who loved it first may have changed their taste and would not be happy anymore. In short you will never ever be all done with your UI work. So what can you do to succeed in an environment that changes all the time? A few things always help: make it customizable and allow users to personalize (if possible). Define personas and profiles you are targeting, learn from them and have them test your UI before it gets implemented and keep UI work on project every single release so that you get a chance to update the looks as the fashion changes.

Lesson 6. Software maintainability is a key to longer life for any software.
This is a pain most of us working on software that has lived a long life, have faced so many times. Countless hours of productive development time has been spent trying to figure out what a piece of software does, how a system works and what will happen if the code logic was changed. We have all heard of side effects in piece of software that can challenge the best of analytical minds. So why does maintainability get such a low priority in software development. First it is laborious work that has no impact on software features. When your reward system recognizes developers who do magic with their software no matter what they do inside, that’s what they will focus on. If you lucky, you will have that super developer on your staff for more than a few years working on the same software. Unfortunately our industry does not work that way and a career path for a great developer keeps them moving. That brings us back to maintainability of the software. All software is designed with an intention that it will keep selling over time (every tried to figure out why the margins on software sale are so high). If that is the intention, you should keep maintainability on design goal on all your projects. Developing maintainable software is a disciplined approach to software development. It does take time and it is usually difficult to measure but it is as important as some of your features. So what makes software maintainable? Usually having a design/architecture doc is useful but inevitably you will hear that that goes out of sync and cannot be relied upon. Usually what I have seen work the best is using the code itself to keep everything about the code inside it. Who designed it, what it was designed for, what are known limitations, what are the assumptions, did anyone fix a bug there and what did they do, what bug was fixed (a reference to bug tracking system helps) should all be captured in the code or alongside the code. Code comments should be written while code is being written just because they are the most relevant and accurate at that time. Code intent (call it design for the module) should be right there with the module being designed. All developers design before coding, they can easily write it there (provided they are motivated to do that). If a cryptic and hard to read code is being developed, it should need more comments and design details than anything else. The system design (original design) and changes to it should be maintained in sync through code management system (even though it may stress your code management system a bit). There is a lot one can do to save time and money over the life of a code. This is going to become even more relevant with SOA and assembled software. One measure for maintainable software is the time require to have a new developer become productive on an existing software (the shorter the time the better maintained your code is).

Lesson 7. Development process should help development produce good quality software, if it comes in your way change it.
This is my favorite topic of discussion with management as well as developers. I am doing this because that’s what you are supposed to do. The process calls for it and if I do not follow the process, I will not be able to check the code in or something else like that. While I agree that process and guidelines are necessary and important but lets’ not forget the purpose for those. Software isn’t a bi-product of processes and guidelines, software is the product. Process should make it easier to develop software, ensure that all requirements are being met. This is why processes should be reviewed periodically with an intention to change and fix it as necessary. This is one of the many things that I would listen to developers and first level managers for. They should be trained to recognize when a process is not working for them. They should be able to identify shortcomings and someone responsible should review the processes and change it to make sure that the intentions behind those processes are still being taken care of without overburdening developers. Automation helps as well. Simpler, meaningful and reasonable processes and guidelines are likely to aid developers in their daily job as well as help get the best product out and everything should be done to get to the state where developers start to feel that guidelines are processes are their friends and they have a good say in shaping these. Process agility is a key to the success of a development team. It should also be recognized that the same processes and practices may not work well with all the teams. The experience level of developers and the nature of project should help shape processes necessary. Cost of changing process is far less than extra time your developers spend getting frustrated because of outdated and meaningless processes.

Lesson 8. Take agility with a grain of salt; result –oriented software development is what agility should help you gain.
Agile development methodology; if you are not following it, you are not current. It has become a fashionable new term for management to say – yeah we follow agile methodology in our development. While it sounds cool to say you are agile, stop and take some time to see what are you agile about. Agility isn’t just following Scrum; it is a way to become result-oriented software development team. Lots of time I have seen that software development teams are either forced into following agile methodology or they opt into it because everyone else is doing it. They usually know what to do but they don’t know what to expect. What is also not clear to most is that not all parts of software development benefit from agile methods; The truth is that agile methodology can hurt the overall development if it is applied without proper thought. For example the kind of agility needed for an online SaaS software development shop is quite different from what is needed for traditional development products that get shipped to customer. The right participation in agile method is also key. Program management, quality team, deployment and even documentation team should follow agile method and synchronize with other teams at appropriate time. Architecture, design and requirement gathering is usually not amenable to agile methods (at least the same kind of agile methods that something like Scrum proposes). They can be done in progressive detail as a complete phase before development kicks in. Through my experience on reviewing many projects, I have seen that some of the projects took a lot longer to complete even though they followed the methodology as well as they knew how to follow. Agility is a great achievement for any project team but they have to figure out how they need to adopt it, what would be the impact, what are the expected outcomes and which activities should be pre-conditions or post activities. A lot needs to be considered including involvement of all teams in coming up with agile process before actually executing a project with it. The price for making a mistake could be high and sometimes benefits are never realized. The right kind of agility is what helps reach the ultimate goal- result-oriented software development where everyone involved had a clear insight into how the progress is being made, they can course correct as necessary without having to take a blind approach and just go on faith. While one should take great care and do analysis before adopting agile methodologies, not adopting one can do more harm than good.

Lesson 9. A great software engineer never stops working.
I bet you are wondering about this. I thought of picking this topic after hearing (and sometimes practicing) that many teams wanted their developers to log their time to measure productivity and I tried to see how one can measure this. The only thing you can measure is the time you spend typing in from of computer screen but is that really the place where software is created? Sometimes yes but not always. Developing software at its core is a problem solving exercise and when you have a problem, you think about it everywhere. While watching TV, playing soccer, driving or (for some very dedicated individuals) while sleeping. Now how do you measure that as part of your work? The fact is that when presented with real challenging issues, a software engineer will devote all their time until they solve the problem or find someone to help with that. It is just in their nature, their entire engineering training and required educational background shapes them that way. So the real reason I brought this up is to make you re-consider asking your software engineers to log hours to declare how productive they have been. Just use their accomplishment, commitments and goals to measure them with. Forcing software engineers to declare that they work 40 hours a week or more will get you exactly that answer and you know as much as your engineer that there is no real productive measure in knowing that.

Lesson 10. Know the keys to writing great software; magic isn’t one of them.
No matter what development methodology you decide to follow for your software development there are some fundamental things that you should seriously consider accomplishing in order to get quality software to your customers. Keep in mind what I am writing here applies to packaged software development (one can modify these steps for SaaS model but I won’t be covering that in this article):

• Understand requirements and use-cases: This helps your team understand what they are up against, what assumptions they can make and how they can proceed with their activities. Like every good reviewer, challenge the requirements and question it’s validity. Even though your program manager may be presenting the requirements to you, they need to be able to confidently explain and defend each and every one of those. A requirement may be coming from imagination (new markets), customer demands, customer feedback, steering groups, industry changes, competition and so on. It is a good idea to know what they are.
• Assess the needs: Next you should assess the needs for what major software blocks are going to be needed and how they could fit together. In the process of doing this find out what others within your company may already have done (you can simply use their code) or if there are some know publications (make sure you have rights to use it) that address what you are trying to do.
• Gather what you can find and identify the gaps: Gather the software/modules you can get and identify where you will need to develop new software. In the process also identify risk area (areas that you don’t know much about).
• Prototype: There are several reasons for doing this. First you can eliminate or highlight situations that you thought were risky. Get a sense of is the problem can be solved or a different approach is needed and if there are multiple ways to solve a problem which path will be the best to take. You are also getting insight into what it will take to develop software and that will help you plan and estimate better. This is the first milestone where course correction in terms of planning and schedule should be made. You would also find out if you have to license/acquire technology or if your endeavor is infeasible and should be abandoned. If you are able to carry on, this is your first chance to demo something and improve your team’s credibility.
• Design and Architecture: By now you have a great idea about elements needed to build the software. Go ahead and build it … on paper. Write down design, complete architecture, deployment scenarios, test scenarios and also demo scenarios. You know what you need to build and the parts involved, you should be able to accomplish design to a fair amount. If is ok now to become agile and identify isolated areas that have defined interfaces and behaviors but can be designed in detail later. Getting on the paper makes everyone know the system better, question and challenge assumption, incorporate performance and scale parameters, address maintainability and so on. This phase does take time and the whole team is involved but by the end, your team would know the order in which the development will take place, how will systems communicate, how they will fail and recover, are you getting software from inside or acquiring from elsewhere and other details. All that remains is to implement.
• Code and document: the previous exercise will give you enough confidence if not all details and a good plan with reliable schedule to complete this phase faster than ever before and perhaps with fewer high impact mistakes. This phase could get a lot smaller and pain-free if all the activities are being taken up accurately. This is great phase to follow full agile method for so you can show progress as you go along finish design details for you was an isolated module and engage documentation and quality teams to start their work. Installation and release teams can get started right here and start to work with shell of an application while features are being put in. Program managers can start to verify use-cases and at some point engage close customers for feedback. You can track to your schedule and see if you need to adjust. By the time coding is done, very little is now remaining to complete the project and hand it over to quality team for final test and sign off, after this phase is completed.
• Verify use-case, get user feedback, and fix bugs (no new features): Now the software is ready for final phase of testing user feedback, demos, and bug fixes. If everything else has gone as planned before this phase, one should not be surprised if not too many bugs are discovered in this phase and many of the really bad issues should not show up.

What I am describing here is not a methodology for software development rather than distinct activities that should be performed. If you are following agile methods then you can imagine some of these activities will be mixed in as necessary for every iteration. I would strongly recommend not to short circuit design and analysis phase and force that in an agile method since that has a huge chance of making all you agile efforts ineffective or even harmful. I have seen one too many projects suffer through this painful exercise and in the end they did not benefit at all from agile method (although not measured but it may have cost them more due to course correction in between the project). These mistakes will force a lot of back and forth during iterations and will cause developers to wait for corrections to be made or will force them to go back to previous iteration for re-design. Requirement analysis and design phase will help eliminate that and will help better plan and schedule for agile methods to produce desired results.

Editor’s note: This is a guest post on Lean Software Development by Corey Ladas. If you don’t know Corey, he is a product development methodologist extraordinaire.  if you missed Corey’s previous post, Introduction to Lean Software Development, be sure to check it out.  This is a follow up post for readers who wanted more information on some principles, patterns, and practices that could help support Lean Software Development.

Lean Thinking is a paradigm of production and can’t easily be reduced to a process recipe.  The particular form of any Lean process will always depend upon the form of the product that is created by that process.  However, any Lean process will realize a few essential principles.  If we apply these Lean principles to software development, we may find some practices that express those principles in a way that is useful and sensible for the medium.

One Piece Flow
A central concept in Lean is that planning, executing, and delivering work in small batches minimizes waste. The ideal limit of working in small batches is the single unit. Creating one piece at a time with zero waste is the ideal of one-piece flow.

A Lean goal in software development would be to define a minimum batch size that delivers value to stakeholders.  One such approach for product development is the minimum marketable feature (MMF).  Not all software development is product development, so “marketable” is not always the right criterion.  But every enterprise has some kind of goal that determines value, and this goal can be applied to a minimum stakeholder-valued feature.

There may be many steps involved with the creation of such an atomic work product.  Some of the work that is scheduled in association with a product will directly add value to the product. Other work may be incidental or even unnecessary.  It is important to distinguish between these categories.  Value stream maps describe the sequence of value-adding improvements that are necessary to deliver the product.  The “flow” in one-piece flow means that these activities should be performed in an uninterrupted sequence from start to finish.

Dividing the work into independent business-valued features enables the staged delivery of those features.  Your highest-value customers may receive most of their benefit from some subset of your planned features and would prefer to take earlier delivery of a smaller system.  Revenue earned from these customers can fund your ongoing development in an incremental funding model.

An incremental delivery strategy may still be executed against a predetermined plan.  An even more adaptive strategy is evolutionary delivery, where frequent deliveries are made in response to evolving market conditions and each delivery is a complete, fully functional system.  Many hosted applications and open-source projects fit this model.  Tom Gilb has written extensively on engineering practices than enable evolutionary delivery at a high level of rigor and quality.

The extreme interpretation of evolutionary delivery is continuous deployment, where very small incremental improvements are released to production at a high frequency.  Flickr, for example, releases new code to production every 30 minutes.  IMVU releases every 8 minutes.  This level of operation transforms the metaphor of software development from the construction of an object to the refinement of a fluid.

Let the Market Pull Value from the System
If we are very flexible in our delivery capability, then we can respond to market conditions as they evolve.  Rather than deliver a feature in a planned release 18 months from now, we can deliver it next month if the market demands.  The faster we can plan and deliver a new feature, the more we can allow the market to pull value from the system.

Customers may not have the right understanding to express what they really need.  Allowing the market to pull will still require interpretation from a producer.  In order to understand what the customer really needs, you should go and see for yourself the need that the customer is trying to satisfy.   The methods of Quality Function Deployment allow us to discover and express the voice of the customer in a way that we can translate into detailed and actionable product specifications.

If we deliver work in high-frequency iteration, we will have to find a way to make that work flow smoothly within the development organization.    If that value stream includes operations that require the services of specialized or scarce resources, then we will need a way to coordinate the scheduling of those resources.  A kanban-controlled workflow regulates the productivity of individual process steps in the value stream, so that each step produces only at the rate that is required by the pull of the market.  A kanban system creates an internal market where downstream consumers pull value from upstream producers.

Pull systems enable us to create value just-in-time.  Market value does not always come in uniformly-sized chunks and sometimes we can see changes in market trends before they are expressed as specific product demands.  We can strike a balance between meeting the demand of the present and anticipating the needs of the future with just-enough-planning.  Rolling wave planning scales planning detail according to time, so that we make detailed plans about things that will happen very soon, and more general plans about things that will happen in the future.  The further the time horizon, the less specific the plan.  Then we must revisit the plan frequently as we learn new things about market conditions.

Real options are an approach to project management that are analogous to financial options in investment management.  A real option may allow us to purchase in the right to defer a management decision to some future date.  When that date arrives we can exercise the option or allow it to expire.  We can then create a planning portfolio of options instead of a portfolio of commitments.  Rolling wave planning and staged delivery are examples of options thinking.

Set-based development means that we may pursue multiple competing design alternatives simultaneously, and defer commitment to any particular design alternative until we have more information.  This is another example of options thinking.  Distributed version control systems enable inexpensive branching and merging and thereby facilitate evolutionary selection of the fittest features and designs.  Some well-known large open source projects operate according to a set-based strategy.

Visual Control
Another key principle of Lean thinking is that we should optimize the whole system, as a system.  Uncoordinated local optimizations never lead to a system that is optimized as a whole.  In order to optimize the system as a whole, it helps if we can see the system as a whole, and this leads us to the practice of visual control.  Visual controls are usually created to illuminate the relationship between a local process and the system, in order to provide the operators of the local process with context.

A popular type of visual control in software development is the card wall.  If a card wall is used in conjunction with a kanban system, then we might call it a heijunka board or kanban board.  A heijunka board is used to implement a process called production leveling, where the parts of the system operate at a consistent rate, without booms and busts, and the flow of work through the system is smooth.  A card wall can also be used to implement the practice of the andon signal, which is used to communicate a problem in the development process.

Visual controls work best when they are ubiquitous and inescapable, but we can always enforce a minimum shared understanding with a daily stand-up meeting.

Build Quality In
A Lean development process should not allow defective work to move downstream.  A policy of one-piece flow enables a policy of 100% inspection, with an aim towards discovery of any defects at the earliest possible moment.  This translates directly to software development in the form of design review and code inspection, which are greatly facilitated by small batch size and pull workflow.  When a defect is discovered, a Lean process should stop the line and apply root-cause analysis in order to discover the source of the defect.  If the root cause is repeatable and preventable, then we should adapt our process to prevent that kind of defect in the future.

Jidoka is a philosophy of optimizing the balance of work between people and machines, so that people only do work that people are good at and machines only do work that machines are good at.  Lean processes use automation, but always in the service of and under the control of a human operator.  A Lean process should prefer simple tools.  Over-reliance on complex tools and technology may lead a business to be enslaved by the capability of their technology and disconnected from customer value.  Lean tools should be as flexible as the marketplace they serve.

Continuous integration is a automation practice that reduces work-in-process and can greatly facilitate the early discovery of defects.  Design-by-Contract instruments source code to self-detect design anomalies.  Automated design verification can then be accomplished with static analysis.  Specification-based verification strikes a nice balance between work that people are good at (expressing intent) versus work that machines are good at (exhaustive search).  Requirements specifications can also be made verifiable in this way.

Continuous Improvement
The PDSA (or PDCA) cycle is a time-tested approach to continuous improvement.  Plan the work that you need to do, Do the work, Study the results of the work you have done, and Act on what you learn in order to improve.  The application of Lean principles create an environment where the PDSA cycle can be sustainable and effective.

Standard work is the foundation of continuous improvement.  Standard work in Lean means that the operators of a process reach a consensus about appropriate results of a process and the best known methods to achieve them.  A work standard only remains the standard until a better way is discovered, which then becomes the new standard.  These standards should never be imposed by an external agent. In software development, such standards may take the form of design rules, coding rules, checklists, inspection procedures, or even the workflow itself.  PDSA is the process which drives the evolution of standards.

Throughput metrics provide useful information to discover the causes and effects of production problems.  The primary throughput metrics are time-series metrics, so we can associate changes in the metrics with known historical events.  Inventory levels are a leading indicator of lead time, which we can use to guide management action.  A stable throughput process is predictable and enables estimation of future deliveries based on historical data, instead of guessing.

References

• Corey’s blog:  http://www.LeanSoftwareEngineering.com
• Lean Thinking, James Womack and Daniel Jones
• Software by Numbers, Denning and Cleland-Huang
• Principles of Software Engineering Mangement, Tom Gilb
• Lean Software Strategies, Peter Middleton and James Sutton
• Implementing Lean Software Development, Mary and Tom Poppendieck
• The Principles of Product Development Flow, Donald G. Reinertsen
• Scrumban, Corey Ladas

Photo by Cayusa.

Editor’s note: This is a guest post on Lean Software Development by Corey Ladas. If you don’t know Corey, he’s a product development methodologist. He brings more to the table than most on engineering process because of his background working on integrated mechanical / electrical / software products.  What I like about Corey is his ability to take start of the art and bridge the gap with state of the practice. He has an uncanny ability to boil complex things down into their essence. without further ado, here’s Corey with an introduction to Lean Software Development …

The application of Lean principles to software development process requires interpretation, and there is more than one school of thought about the best interpretation of Lean Software Development.  Some focus on Lean principles applied to common development practices, some focus on workflow management, others focus on complementary product development processes used by Toyota and other Lean producers.
Five Principles of Lean Thinking
The principles of Lean Thinking are necessarily abstract compared to the detailed methods used by Toyota for making cars, but this generalization allows of to think of a great variety of business applications.  The authors of Lean Thinking, Jim Womack and Daniel Jones, define the five core principles as:

• Specify value from the standpoint of the end customer by product family.
• Identify all the steps in the value stream for each product family, eliminating every step and every action and every practice that does not create value.
• Make the remaining value-creating steps occur in a tight and integrated sequence so the product will flow smoothly toward the customer.
• As flow is introduced, let customers pull value from the next upstream activity.
• As these steps lead to greater transparency, enabling managers and teams to eliminate further waste, pursue perfection through continuous improvement.

Why Lean - The origin of Lean Thinking in the Toyota Production System
The history of business over the last two centuries is largely the history of industrial mass production.  Methods of accounting, project management, organizational design, and many other institutions of business culture developed in service of the needs of mass production.  The success of mass production has been so profound and so enduring that its practices have become synonymous with the practice of business in general, even when those practices are inappropriate for the specific problem at hand.  Mass production became traditional, traditional practice is taught in business school, and when all you have is a hammer, everything looks like a nail.
Unfortunately, there are a wide and increasing number of business problems for which mass production thinking is poorly suited.  Software development would be a major category.  There has been an ongoing mismatch between traditional business practices and the needs of software development throughout the entire history of software development — a fact which has been greatly lamented over the years, often under the label of “The Software Crisis.”

Sometimes it takes an historical event to disrupt an historical process.  In the case of mass production, it was the recovery of post-World War 2 Japan, and the emergence of the Toyota Motor Company as a global producer.  Mass production assumes a) capital is scarce and must be optimized, and b) the market wants large quantities of a limited variety of goods.  Toyota found itself in a situation where a) labor is scarce and must be optimized, and b) the market wants limited quantities of a wide variety of goods.  Japanese consumers expected comparable value and quality from Japanese producers as they did from American producers, but Toyota could not support the economics of mass production in the marketplace of postwar Japan.  Faced with such circumstances, Toyota’s only options were to exit the business or get very creative about how to make automobiles.  They got creative, and today they are the largest and most successful auto manufacturer in the world.

The problems that Toyota faced foreshadowed the problems that an increasing number of businesses would face in the late 20th century:  customers want more variety and better quality, and they want it now.  Traditional business practices are often poorly suited to deal with these expectations, and management theorists became increasingly restless in their pursuit of new understanding.  Much as the industrial practice of yesteryear evolved into more general business practice, the principles of the Toyota Production System were abstracted into the general business philosophy we now call Lean.

The Metaphor School of Lean Software Development
Since software development is really nothing like assembling an automobile, it will require some interpretation in order to make sense of Lean principles. The first school of thought in Lean Software Development is the interpretation of Lean principles in terms of native software development methodology.  If we can identify existing methods that are analogous to concepts in Lean, then this will help us deliver the value that Lean promises or help us align software development teams with a surrounding Lean business.

The founders and chief proponents of this school of thought are Mary and Tom Poppendieck, publishers of the popular Lean Software Development series of books.  The Poppendiecks interpret the general Lean principles into something more intelligible for software development:

• Eliminate Waste
• Create Knowledge
• Build Quality In
• Defer Commitment
• Deliver Fast
• Respect People
• Improve the System

This approach to Lean software development has been attractive to some who believe that software is fundamentally a craftwork discipline.  The individual craft mode of production is inconsistent with a strict interpretation of Lean, so craftwork proponents that are sympathetic to Lean tend to favor a more abstract interpretation.

The Agile software movement have been the most visible proponents of the craftwork philosophy in recent years.  The part of the Agile community that has adopted Lean thinking typically calls their flavor Lean/Agile development.  Lean/Agile proponents typically describe practices of methods like Scrum or Extreme Programming in terms of Lean principles, and sometimes modify or elaborate on those practices accordingly.  Craig Larman and Bas Vodde are notable proponents of this view, as expressed in their recent book Scaling Lean & Agile Development.  Alan Shalloway and Curt Hibbs are also well-known advocates of this approach.

The Workflow School of Lean Software Development
Another major school of Lean thinking in software development is more focused on management and is more comfortable with words like “software engineering.”  This “workflow school” believes that the majority of software development processes can be described in terms of…workflow, and that any workflow process is directly subject to the five principles of Lean Thinking, without need to abstract away the details.  There have been a few false starts since the 1980’s, but the modern founder of this approach is generally considered to be Donald Reinertsen.

Peter Middleton and James Sutton are advocates of a Lean approach to software engineering, including the application of systems engineering methods like Quality Function Deployment and software engineering methods like formal specification.  Enthusiasts of Tom Gilb’s evolutionary delivery approach to software engineering have been reinterpreting and updating some of Gilb’s methods in terms of Lean ideas.

The workflow school has experienced substantial growth over the last two years, with the adoption of the kanban style of workflow management popularized by David Anderson.  My book, Scrumban, is the first book to describe the kanban approach in detail, but there are a growing number of sources online.

Describing Lean software development in terms of “schools” might paint a more adversarial picture than is actually the case.  Most teams using kanban systems today would consider themselves to be Agile teams, but perhaps an emerging second generation of Agile that embraces Lean more openly.

Additional Resources

• Corey’s Blog – http://www.LeanSoftwareEngineering.com/
• Lean Thinking, James Womack and Daniel Jones
• Lean Software Development, Mary and Tom Poppendieck
• Scrumban: Essays on Kanban Systems for Lean Software Development, Corey Ladas

Photo by One man’s perspective.

The following is a short list of some of the project practices that have helped me maximize impact, while shipping  on time and on budget.

Verification

• Dog fooding.  Throughout the project, I have the team dog food what we build.  See Dog fooding (WIkipedia.)
• 5 customers.  This is an critical check throughout the project that 5 customers stand behind the project.   They key is these are 5 customers that actually use the deliverable.
• Product teams stand behind / promote.   Given that I create prescriptive guidance, it’s vital that the product teams can stand behind what I create.  If they aren’t promoting it and using it to solve customer problems, then something is off.
• Scenario Evaluations.  Walking the scenarios and testing against scenarios is one of the most effective ways to verify the solution against the problem.  I try to identify key criteria so the team knows what to look for.
• Sign-off by key stake-holders.  The key is to get everybody’s finger prints on it and to make sure they can stand behind it.  It helps avoid the scenario where stakeholders shoot down the project.

Domain Analysis Artifacts

• Question List.  I create a list of what people “ask.”  Knowing the questions people have, verbatim, helps me quickly know what problems people care about.
• Task List (input for scenario frame).  I create a list of what people “do.”  A task list is simply a set of the tasks that users perform.  Ideally, these are goal-based.  As Alan Cooper might put it, “persona-based scenarios with goals.”
• Scenario Frames.   I create a Scenario Frame.  Scenarios (or stories) are a simple way to organize the things that your users do.  Organizing them in a frame makes them easier to manage and share.  See Scenario Frames.
• Real Problem Feedback.   I find concrete instances of real problems.  Finding people who actually share the problem helps.
• Project Specific Personas.  I identify the types of users, along with their context, drivers, and needs.  Personas help with customer empathy.  See Personas at patterns & practices.

Product Team Reviews

• Product Team Reviews.   Regular product team reviews help me keep everybody on the same page.
• Whiteboard reviews.  Whiteboard reviews simply mean rather than any formal slides, we simply review key concepts and ideas on the whiteboard.  This is a lightweight way of checking and sharing information.  They’re easier to organize because they can be done more ad-hoc.
• Modular, incremental reviews.   I try to engage the product teams along the way rather than a big bang at the end.  It’s more effective and let’s us change course as needed.  Most importantly, it let’s us act on the feedback.
• Snapshot Reviews.   I create tickler lists of points for review.  Having a bulleted set of items to review makes reviews much more efficient and helps store and share state for a lot of information.

Execution

• Exec sponsor.   Having an exec sponsor helps the project over rough patches.  Usually, the exec sponsor puts somebody on point as an escalation path and this helps with cross-group issues.
• Cuttable scope.  If you don’t have cuttable scope, your project is at risk.   Cuttable scope means that when you cut something, you actually do gain back time, without messing up quality.  To pull this off, it means having a good idea of discreet incremental chunks of value.

Communication

• Internal project site.  I’ve found that having an internal project site helps have a simple place to point people to let them know what’s going on with the project.
• Agile customer project site.   I find it helpful to have a simple place to share deliverables with customers.  For example, this is our Visual Studio Team System Guidance customer site.  It made it easy to share news, share releases and get customer feedback.
• Team Wiki.  I find it helpful to have a team Wiki to dump information as we go.

My Related Posts

• Lessons Learned in patterns & practices

Photo by Liquid Lucidity.