While Starcraft 2 offers solo play at various levels of difficulty via a campaign and custom battles against the computer A.I. it is the multiplayer matches against other people that most clearly reveal expertise, or the lack of it. Blizzard created a clever ladder system for ranking players that is used in automatically matching players of similar skill levels. The lowest level of the ladder is bronze, followed by silver, gold, platinum, diamond, and finally master. The master league was created post-release by Blizzard for the top 2% of players, and is the home of the true experts in the game. Videos of matches between these highly-ranked players are frequently posted to YouTube by commentators such as HDstarcraft. Watching these expert-level replays, it is interesting to see how effortless the top players make it look to manage the economies and unit production of multiple bases, scout for information on what their opponent is up to, and tactically control with precision units of various abilities in battles. Switching to one of the player's individual views or seeing them using their keyboard is a shocking contrast: they are continually switching viewpoints between different parts of the battlefield blindingly fast and their fingers are a blur on the keyboard. They average two to three mouse clicks or key presses per second the entire game.

The biggest lesson in expertise from Starcraft 2 is that there are no shortcuts to becoming an expert: it takes tons of deliberate practice coupled with deep domain understanding. In Korea, where Starcraft is reportedly considered a national sport, top players are members of teams that spend hours each day training together. Since the game has been out for less than two years, you might think that no one has amassed the approximately 10 years of training that are typically required for true expert status. The original Starcraft, however, has been out for longer than that period of time. Many of the top players of the original Starcraft have quickly achieved mastery in Starcraft 2 despite some significant changes in gameplay. In one account I read of a master level player's ascent up the leagues he stated that he only needed about 6 months to make diamond, but then he went on to explain that he spent almost his entire childhood playing hours upon hours of video games.

I re-learnt this lesson for myself when I got into the game and prepared for multiplayer play. Rather than dive right in, I viewed some instructional videos, mastered (so I thought) the use of hot keys and completed the solo campaign. After some battles against the A.I., I felt I was more than adequately prepared to face league play. A short stint in the practice league reinforced this, so off I went play my 1v1 placement matches to determine my league. To my surprise I promptly lost all 5 matches and ended up near the bottom of bronze! I played a number of additional matches and made some small improvements. My biggest gains, however, came not from playing competitive matches but from seeking out training tips and deliberately practicing various elements of the game. For example, I found in matches that I frequently lost to Protoss players (one of the three races players can choose in the game). So I played a number of A.I. games solely against Protoss and gradually was able to increase the A.I. difficulty that I could consistently beat.

Starcraft 2 is a fun and entertaining game, but if you want to play in multiplayer league games and have a reasonable chance of wining - even in bronze - I recommend studying and practicing. One great source of information for doing so is Shokz's Starcraft 2 Mastery Guide.

Experiencing expertise in Starcraft 2 is a great reminder of the need for us as software developers to incorporate deliberate practice into our day to day activities in order to continue to improve.

The constraints need to push us out of our comfort zone. We need to bump up against the constraints, repeatedly, in order to generate those learning opportunities. The constraints cannot be so harsh, however, that they prevent us from finding solutions that fit within them.

The nature of the constraint dictates the area in which the growth will occur. Twitter's constraint encourages conciseness and the ability to focus on the core message. Writing assessments in classes tend to set the opposite constraint of a minimum number of pages of content in order to encourage deeper exploration of a topic and more hours of practice in writing.

Thinking about this principle in the context of software development made me realize that the many different types of software are often differentiated by the major constraints they face:

Constraints can also be applied to processes or methodologies to provide learning opportunities. I have heard more than one ScrumMaster say they prefer one week iterations for teams new to scrum as a way of learning how to decompose functionality into the smallest possible increments. The concept of stretch goals is similar: set targets beyond the current capabilities of the team in order to push team members out of their comfort zone and seek innovative ways to meet those targets.

How can you use constraints to improve and grow? I encourage you to reflect on this and leave a comment sharing your thoughts.

Drive: The Surprising Truth About What Motivates Us by Daniel Pink. Researchers have discovered that using external motivators - what Daniel calls the carrot and the stick - is not only generally ineffective for creative, knowledge-based work, but can even be harmful. The traditional view in economics and business management of people as rational wealth-maximizing agents is flawed as demonstrated by numerous experiments and real-life events. Intrinsic motivation is the missing ingredient with three elements: autonomy, mastery, and purpose. The book is inspiring both because of the hopeful future it depicts for business based on intrinsic motivation and because of the numerous strategies and examples it provides on how to redesign organizations to use these principles.

Agile Retrospectives: Making Good Teams Great by Esther Derby and Diana Larsen. I found this book both insightful and eminently practical. The authors explain the ineffectiveness of common, overly-simplistic approaches to running retrospectives and describe a five stage model for structuring a retrospective’s agenda. They then present a wide variety of activities for each of these five stages. I was able to easily put the concepts and activities presented in this book into practice and I feel that it has made a dramatic difference in the effectiveness of the retrospectives and other meetings I facilitate.

How to Measure Anything: Finding the Value of Intangibles in Business by Douglas Hubbard. The author in the first few chapters presents his philosophy and rational approach to measurement while demolishing frequently-held myths about measuring, especially those commonly touted in business. I loved how his approach seemed conceptually simple yet powerful, deriving from a clarified definition of what measurement means. I felt like I experienced a paradigm shift after reading this material and now view measurement differently. Prime examples of where this would apply in the field of software development are estimation of effort and schedule, especially high-level initial project estimation, and measurement of quality including customer satisfaction. The book then shifts into presenting various measurement methods involving varying levels of statistics. Despite my inexperience with anything beyond introductory statistics, I was able to follow along just fine. To really adopt these methods, however, I need to study and practice these methods more carefully. Douglas does a good job of providing easy ways to apply these statistics for the layperson ranging from simple lookup tables to Excel formulas, so they are quite accessible. But even if the statistics do not interest you, I believe the first few sections are so remarkable that they are worth reading on their own.

While I read tons of blog posts and tweets, I still find books extremely valuable for gaining the deeper insights and perspectives based on the authors' experiences and mindset that require immersion across multiple chapters to really absorb. So I highly recommend you check these books out.

Adopting Test Driven Development

The boldest idea I heard was in response to my question of how to encourage the adoption of test driven development (TDD). The answer consisted of this process:

1. Clearly communicate to the team the expectation that all production code will be produced with tests.
2. Wait and monitor code check-ins until you see code checked in without tests.
3. Delete this untested code and commit the change.
4. Communicate to the affected developer that you found some code that was not necessary because the tests still passed after removing it. Diabolical laughter optional :)

This sounds extreme, but the team I was talking to actually used this in the formative early stages of building their team and the use of TDD has become a standard practice on the team. I think applying this at the start of a project with a new team is the best timing and makes the most sense, but I may have to try it mid-project (my team, watch out :)

I also learned of a different approach to writing individual tests that basically involves starting at the end and working backwards. Start first with the asserts that specify the desired result, then write the execution of the method under test which covers how the result will be obtained, and then finally write the setup code which provides the necessary inputs. This approach is very much a pull approach (in the lean sense) - each step serves as the specification for what needs to be done in the next step. As such, it might be an easier approach for newcomers to unit testing.

Adopting Pair Programming

I asked about dealing with resistance to adopting pair programming, especially the tendency of pairs to collaborate jointly for only a short time before reverting to working separately, each at their own computer. The answer was to take away someones computer, which leaves them with no choice but to pair with someone else on the team.

Environment factors can also help or hinder pairing. The Calgary teams have their workstations set up to allow people to sit side-by-side in front of the same machine. I think this layout is very important for successful long-duration pairing, and I switched my own cubicle over to this layout a while ago. The Calgary teams, however, took this setup one step further and have a second keyboard and mouse for each of their workstations. This has several benefits in terms of encouraging pairing:

• It communicates visually the expectation that two people will work at this computer rather than one.
• It eliminates concerns over using another person's keyboard. The 'owner' of that workstation has their dedicated keyboard, with the second keyboard reserved for guests. Whether the concern is over germs or over intruding on someones property/space, having only one keyboard produces a reluctance on the part of the visitor to drive.
• A common problem in pairing is for the person who is not driving to become too passive. Providing a second keyboard gives them the opportunity to jump in at any point (even when the driver does not want to relinquish control), and having the keyboard waiting in front of them is a subtle reminder to remain actively involved.

Using Task Boards

All the teams use task boards consisting of cards in various columns on a whiteboard, wall, or even a window. My team has recently switched to using a task board and I really like it in terms of it visualizing the work in progress and serving as a hub for discussions, like in the daily scrum. Given my experience and its broad use in Calgary, I am going to more actively promote its use.

Every team seems to have variations in how the task boards are used, but there were some commonalities across the Calgary teams. All teams used large cards - about the size of half a normal 8.5 x 11 page. Compared to the small post-it-note-sized cards my team uses this is a lot more real estate. These cards are made from colored paper cut in half that allows different colors to be used for different types of activities (e.g. defects, stories, and tasks). One team printed out defect reports (from JIRA) on regular paper and folded them in half to attach them to the wall. Another team attached printed requirements (with tests) folded in half to user stories. The teams all had relatively few columns for their task board - usually not more than four consisting of "In Sprint", "In Progress", "In Testing", and "Done".

Professional Development

The Calgary teams have a very strong culture of professional development that manifests in a number of ways. The most visible manifestation is my seeing many recent software development or I.T. books scattered around the office, many of which are books on my reading list (I may have to do an office raid :).

What I consider the most significant manifestation of this culture is the existence of a professional development group for senior developers. This group holds a number of activities that include periodic presentations by members on technical topics, book reading groups to jointly go through particular books, and Friday noon viewings of videos relating to software development.

One of the technical leads had an interesting rationale for doing professional development: not doing it is essentially stealing from your clients in the future. If you spend five percent of your time doing professional development and improve by five percent per year, then you will break even after the first year and show a benefit in future years: your output will be higher than before, even after subtracting the five percent. So not doing professional development will leave your client shortchanged in the future. If you let that trend continue long enough, you will eventually lose your client.

Summary

I had a great time and enjoyed being challenged with new ideas and perspectives on software development. I believe that visiting other teams or companies and seeing first-hand how they do things is quite beneficial. I encourage you to look for opportunities to do this and I hope to do more of it in the future. Thanks CGI Calgary!

My plan, therefore, is to have a series of posts over time, starting with this one, that list the books and key ideas I have found noteworthy. I decided to title the series “Remarkable Books”. The reading I do is mostly focused on the fields of software development, information technology, business, and personal development so the majority of books I discuss will come from these areas.

Without further ado, here’s the first list.

It's Your Ship: Management Techniques from the Best Damn Ship in the Navyby Captain D. Michael Abrashoff. The command and control style of management is obsolete. The author, a former commander of the US Navy ship Benfold, demonstrates through his personal journey that even the military - the one place you would think command & control management would work - benefits from a more enlightened leadership style based on caring about your people, communicating constantly about your objectives, and challenging them to be the best.

Never Eat Alone: And Other Secrets to Success, One Relationship at a Time by Keith Ferrazzi. He passionately presents his life philosophy of connecting with others and establishing relationships to form a powerful personal network. His examples demonstrate the high value of such a network while revealing that it is really about altruistically helping others in need. Ironically, the act of helping without expectation of reciprocation is what creates such a powerful and valuable network. He also provides insights into the lifestyle of C-level executives of large companies.

Master Your Workday Now!: Proven Strategies to Control Chaos, Create Outcomes, & Connect Your Work to Who You Really Are by Michael Linenberger. I view this book as the successor to Getting Things Done, as it provides what I believe is an improved productivity and task management system based on a more robust conceptual foundation. I have implemented significant portions of Michael’s system already and am quite pleased with the results.

The China Study: The Most Comprehensive Study of Nutrition Ever Conducted and the Startling Implications for Diet, Weight Loss and Long-term Health by Colin and Thomas Campbell. This book is in the field of nutrition and health, which is outside of what I normally cover on this site, but the simplicity and significance of this book’s message was so powerful that I had to pass it on. The message is this: Nutrition – what you eat – is an extremely significant factor in determining your health (specifically, whether you remain free of chronic diseases), and many scientific studies demonstrate that a primarily plant-based diet is significantly healthier than a diet with higher levels of animal-based foods such as meat and dairy.

In creating this list I started to flip through some of these books again and was re-inspired by what they had to say. I highly recommend you check them out.

Some authors recommend focusing on improving your (or others) weaknesses. They generally believe that being well-rounded is important, and a common analogy is a chain of many links only being as strong as the weakest chain. The strongest case for this position I feel comes from the entrepreneur literature: for a business to be profitable, you not only need a good product or service, but you also need the marketing and sales to have sufficient sales, and the financial management to manage your cash flow and ensure profitability. A weakness in just one area can jeopardize your entire business.

Other authors recommend focusing on developing your strengths. A common argument is that building specific expertise generates the most value, and that it is easier to improve areas of natural ability than weaknesses. Areas of weakness can be delegated or outsourced to others. This recommendation corresponds with the general trend in the labor market of increased specialization.

As I have observed the performance of individuals and teams and dealt with employee performance problems, I have come to realize that this strength / weakness categorization is largely artificial and is not the best model.

I have instead adopted a model based on defining the minimum and optimal thresholds of competence for different aspects of a specific role. The minimum threshold defines the level under which a person will fail (have inadequate performance) in the given role. As your ability increases above the minimum threshold, your performance in the given role improves until you reach the optimal threshold. Beyond this point, increased ability will not improve performance. See the diagram below for a visual representation.

This model accounts for the phenomenon where people who have been doing well or even excelling in a particular position suddenly encounter difficulties when moved into a different position. The reason is that the new role demands a different set of thresholds for which the person falls below the minimum in one or more areas. The classic example is taking an exceptional software developer and promoting them to a manager. This person’s software development skills now exceed the optimal threshold required for a manager, whereas the communication and management minimum thresholds required as a manager are much higher.

The impact of what are traditionally considered strengths or weaknesses depends on the particular role. In some cases a personal weakness may still at a sufficient level to exceed the minimum threshold of competence. One example is having a fear of public speaking (which is apparently quite common). For the typical software developer position, the minimum threshold required for public speaking is very low – a developer just needs to be able to participate in team meetings and group discussions. So this weakness is not particularly relevant for the role. In other cases the team has mitigation strategies in place to address common weaknesses, thus lowering the minimum threshold required for certain roles. One example is developers performing manual testing. This is often not a strong ability for many developers due to the different mindsets required. So development teams incorporate dedicated testers to address this issue.

If personal strengths and weaknesses are misaligned with a role’s minimum and optimal thresholds, with a person being above the optimal and below the minimum in a number of areas, then this generally indicates that the person is in the wrong role.

Even personal strengths may fall below the minimum threshold of competence. This often indicates that the person has been given an assignment too difficult or challenging for their level of experience. One example is giving a good junior developer extremely complex functionality to implement from scratch without guidance. A senior developer could get the job done, but the junior lacks the knowledge and experience – their ability falls below the minimum threshold, despite being a strength for them personally.

A common mistake is to continue to focus on developing your strengths after you exceed the optimal threshold, due to a logical slippery slope. If you begin a new role with most areas below the optimal level, then you will naturally be motivated to improve your strengths and see a corresponding improvement in performance. This motivates you to continue to improve in these areas, even after they exceed the optimal threshold. Malcolm Gladwell in his book Outliers the Story of Success provides a specific example of this phenomena dealing with I.Q. Most people believe that being smart helps one succeed in most areas of life, and that having an even higher genius-level I.Q would be better. I admit to having shared this belief. The extensive research study discussed by Malcolm, however, clearly contradicts this by finding that individuals with genius-level I.Q. did no better in terms of career than those who are ‘only’ smart. So across many fields I.Q. does have an optimal threshold as well as a minimum.

Using this model of minimum and optimal thresholds of competence clears up the confusion in the literature on whether to focus on strengths and weaknesses. Ignore those labels and instead focus on how your abilities align with what the minimum and optimal thresholds are for a given role – either your current role or the role you desire.

Quantity of Practice Required

The research is surprisingly consistent on the quantity of high-quality practice necessary: approximately 10,000 hours. This amount of practice seems to take a minimum of about 10 years to achieve which works out to a rate of 20 hours of practice per week, or about 4 hours per day excluding weekends. It is interesting that this rate of 4 hours per day corresponds to what the research says is the apparent maximum amount of quality practice that can be performed each day. The activity being practiced can be performed for longer, but improvements due to practice do not occur. The reason for this limitation is mental: deliberate practice requires high levels of concerted mental effort that can only be maintained for a limited duration, and a period of sleep is needed during which the brain consolidates the learning that occurred during the day. These limitations explain the 10 year minimum duration: you cannot double the amount of practice you do per day and cut the total duration in half.

Key Elements of High-Quality Practice

It is quite common to see workers with more than 10 years of experience who are nowhere near being an expert. This is because simply performing an activity is not the same as deliberately practicing an activity, although the difference may not always be visible to laypeople. Many people just go through the motions in their work, repeating what they have learned and done before, and thus fail to continue to improve. I have heard this described as having one year of experience repeated for nine years. This explains, therefore, why there is no correlation between the years of 'experience' a developer has and their ability to write code.

So if our goal is to become experts, how do we ensure that we are engaged in high-quality practice rather than just repetitively performing the activity? Here are some key elements of high-quality practice:

• Practice must be specifically designed to improve performance for an individual. The practice must push or stretch the individual beyond their current abilities, outside their comfort zone, but not too hard that it causes anxiety and complete failure.
  

  Each practice session should focus on one (or more) specific elements of performance. The more precise your goal(s) for the session, the better the quality of your practice. You need to seek out what you are not good at. Clearly identifying this yourself can be difficult for a number of reasons. Your ego tends to cause you to fail to notice areas of weakness. You might simply lack knowledge about specific areas. And for areas of performance you know about, it may be difficult for you to evaluate your performance compared to the level of an expert. The guidance of a coach or mentor is therefore extremely helpful. In the realm of sports, even experts like Tiger Woods have coaches to help them improve.

  In business, unlike sports, access to coaches and mentors is much more limited, if not completely non-existent. So as software developers we need to be more creative in finding ways to obtain guidance. One option is to engage in as much pair programming as possible with as wide a variety of developers as possible. You will not always be paired with an expert, but with a wide variety you will encounter situations where your partner reveals some aspect of development you were unaware and can learn from. Another option is to seek out material – blogs, articles, and books – produced by respected developers about coding & design and study their material carefully to absorb their approach to software development. One example of this is Robert C. Martin’s book Clean Code which provides step-by-step transformations of code into a cleaner form. He also provides on his website a presentation and even a video demonstrating the process of doing test-driven development.

• Practice activities must be easily repeatable. To reach expert level requires putting in lots of repetition during practice. The number of repetitions performed by experts during individual practice sessions and over the lifespan of their career can be mind-boggling to laypeople.

  Repetition is especially important for those aspects of a field that normally occur less frequently. If a specific aspect is normally only encountered once a year and you never practice it then you will function essentially as a beginner each time you encounter it.

  A good example of this in the field of software development is performing the actions leading up to the release of the software: integration / stabilization of the software, acceptance testing, and final packaging / deployment. Traditionally under a waterfall methodology this is done once in the last phase of the project. Modern Agile development methods instead mandate more frequent releases, with some potentially being practice releases that are not actually provided to real users. Activities such as code integration or acceptance testing that were traditionally done once prior to a release are done much more frequently as part of each iteration.

• Practice must include feedback regarding the quality of the performance: what was done perfectly versus what can be improved. The more specific the feedback, the easier it is to adjust your actions and tailor future practice sessions to address deficiencies. Feedback should be available immediately, without delay, as part of the practice session.

  One of the best ways of obtaining feedback is through a coach or mentor who can evaluate your performance and make recommendations for improvement. Without such a resource there are still ways of gaining feedback. One approach is to find problems done by an expert, solve them yourself, and then compare your solution to the expert's. Another approach is to regularly set aside time to reflect on your performance and identify specific improvements.

  Obtaining sufficient feedback soon enough is challenging in the field of software development. Many modern development practices are deliberately designed to maximum the feedback developers receive. Test driven development provides immediate feedback regarding the correctness of the code. Pair programming provides immediate feedback regarding the readability and maintainability of the code. Root cause analysis of defects helps identify specific mistakes that practice can address.

• Deliberate practice is mentally highly demanding. This is a consequence of pushing beyond your comfort zone. If you are able to do an activity on auto-pilot, without really thinking, then it is too easy. To grow and improve requires you to be sufficiently challenged.

  Research suggests that one’s ability to sustain mental concentration and focus is the main governing factor determining the amount of effective practice that can be performed. The limit seems to be about 4 to 5 hours per day, divided into sessions of no more than 1 to 1.5 hours in duration. (I find it interesting that this maximum session duration for deliberate practice is the same as the recommended maximum duration for code review sessions, which is no surprise given that both activities require a high level of focus and concentration.) It would be interesting to know what kind of rest and recuperation between practice sessions is recommended, but I have not seen this discussed.

Conclusion

To become an expert requires approximately 10,000 hours of high-quality deliberate practice, which must consist of training activities designed to improve performance, lots of repetition, specific and immediate feedback, and sustained high levels of mental effort.
This is simple to state but is definitely not an easy endeavor to do, which explains why in every field there are so few experts and why the majority are at much lower levels of performance. Yet if becoming an expert is your goal, then this is the path you need to take.

]]> http://www.basilv.com/psd/blog/2010/how-to-become-an-expert-developer/feed 0 http://www.basilv.com/psd/blog/2009/lessons-learned-championing-continuous-improvement http://www.basilv.com/psd/blog/2009/lessons-learned-championing-continuous-improvement#comments Mon, 23 Nov 2009 13:30:10 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=459 For over one year now I have been championing continuous improvement across multiple teams. I have seen and struggled with various problems, some of which I have seen reoccur time and time again, and I have identified successful strategies for dealing with some of these issues. In this article I present my lessons learned in the context of my framework of continuous improvement.

This article is organized into a set of common problems, many of which loosely correspond to the stages of my framework. For each problem I identify various causes that lead to the problem, and then present a solution to resolve or mitigate each cause.




Continuous improvement not being done

This first problem is generic, covering any or all stages of my continuous improvement framework. A team might be holding retrospectives and discussing issues and ideas, but not taking action. Management might be taking action to address issues but not following up. There are some common, general causes responsible for this.

Cause	Solution
People are too busy.	People need to work at a maintainable pace (this is Agile principle #8) with sufficient slack to allow time for continuous improvement.
No room in project budget / schedule.	Continuous improvement should be included as a regular activity in every project.
People do not strongly believe in the benefits that continuous improvement brings.	This is the root cause behind the two prior causes: people will find the time (personally and in projects) if they believe strongly enough in continuous improvement. I have no real solution other than trying to educate and sell others on the benefits of continuous improvement. Unfortunately logical arguments are not enough - you must persuade people emotionally in order to see a lasting change in behavior. Probably the best way to do this is by having people experience successful improvements.
People’s primary duties or more urgent activities consume their attention and time, leaving little to none for continuous improvement.	Each team needs to have a champion of continuous improvement who is responsible for scheduling and facilitating retrospectives and ensuring that actions and follow-up happen afterwards. This is not a full-time role. Most commonly it is part of the duties of the person leading the team (team lead, manager, project manager) or coaching the team (scrum master, agile coach). People need to understand and prioritize non-urgent important activities over urgent, non-important activities, which is a key message of the book First Things First by Steven Covey.




Retrospectives and reflection not being done

Retrospectives for the team and reflection for the individual needs to happen in order to become aware of how the team or individual is doing and identify opportunities for improvement. Yet far too often I have seen teams fail to hold retrospectives despite much encouragement and coaching.

Cause	Solution
Forget to hold retrospective meeting or do reflection.	Regularly schedule these sessions so a pattern is established and they are not forgotten. For retrospectives, hold them either at the end of each iteration or at a minimum frequency of once a month. For personal reflection, I like doing this once a week, as part of my weekly review process.




Ideas not being discussed - only issues

An extremely common pattern I have seen is that when a group first starts holding retrospectives, almost all of the discussion and points raised revolve around issues – essentially complaints about how things are, rather than ideas for how to improve. While this does improve as time passes, subsequent meetings still tend to focus more on the issues rather than ideas. While it is important to be aware of your current state and what your issues are, at some point the discussion must move on to ideas for improvements.

Cause	Solution
Typical behavior pattern. People tend to vent, given an outlet. It is harder to think of ideas for how to solve issues than to identify the issues.	Dedicate a portion of the retrospective to discussing issues and a separate portion to discussing ideas for improvement. One format I like is to first solicit issues, then prioritize them, then for the highest priority issues brainstorm or do root cause analysis to come up with ideas on how to resolve them. It helps to have a strong facilitator to keep the discussion focused.
Root causes of issues are external to the team and/or beyond the team’s capability to resolve.	Management support must be in place so that these types of issues can be escalated to them to be dealt with at the appropriate level. Each management level should actively be doing continuous improvement and ensuring that continuous improvement happens in the level(s) below them.




Ideas not being put into action

Too often I have seen teams discuss issues and ideas during a retrospective, but seen nothing happen afterwards as a result.

Cause	Solution
Lack of clarity regarding what to do next after the retrospective is finished.	Determine the next steps to take regarding the key issues / ideas before leaving the retrospective. As part of the meeting identify and write down action items or an action plan for implementing at least one of the ideas.
Lack of follow-through on completing identified actions.	For each issue / idea, have a clearly identified champion who will own the issue or idea. This person needs to be self-starter who is passionate and motivated to get the idea implemented and the issue resolved.
Lack of focus: team has too many issues / ideas being worked on.	Have the team prioritize the issues and select the top few to focus on. One suggestion I have seen in the lean literature is for the team in each retrospective to pick just one idea to implement, but to then have the team commit to achieving the improvement (or at least make progress) by the next retrospective. I personally like to have as many improvements happen concurrently as the team can handle, which depends on the team and on the ideas being implemented. It is probably best to have each person on the team actively involved with only one improvement at a time.




]]> http://www.basilv.com/psd/blog/2009/lessons-learned-championing-continuous-improvement/feed 1 http://www.basilv.com/psd/blog/2009/using-rotations-to-develop-expertise http://www.basilv.com/psd/blog/2009/using-rotations-to-develop-expertise#comments Fri, 17 Apr 2009 08:39:55 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=358 This article continues on from my prior article Improving Computer Science Degrees for Software Developers on the topic of better methods of developing expertise as software developers in the work place. The original inspiration for these articles is the post Master Craftsman Teams by Robert C. Martin in which he proposed a formalized development path based on the apprentice – journeyman – master craftsman model used by the trades. The specific inspiration for this article is use of rotations in the field of medicine in training medical students, interns, and residents. Trainees spend a fixed period of time working in a particular specialization (e.g. neurology) or unit (e.g. intensive care), after which they rotate into a new assignment.

Benefits of Rotations

The use of rotations provides two key benefits:

1. Rapid learning: People learn most rapidly when placed into new, unfamiliar situations, as opposed to being in the same environment year after year. The initial ramp-up period for new team members often corresponds to the period of increased learning, after which it tapers down. The use of rotations essentially maintains this ramp-up state to realize this enhanced learning on a more ongoing basis.
2. Breadth of experience: Rotation assignments are specifically selected to provide a broad range of experience in the field. This helps trainees determine what they would like to specialize in, and once specialized helps them work more effectively with other specializations. Breadth of experience helps develop that "big picture" understanding of the field and provides better appreciation for how each specialization contributes to it.

While software development is quite a different field from medicine, I believe that the use of rotations is just as beneficial to developing expertise as developers. One example is spending time maintaining or enhancing a preexisting code base tends to teach the importance of having cleanly design and easily understood code – in other words maintainability. Another more general example is developing that breadth of experience tends to provide a better appreciation of the importance of context in determining what development technologies, practices, and methodologies to apply.

Required Rotations

What kinds of rotations would be beneficial for developers? Listed below are the key assignments that I feel every developer should experience:

• Production Support: Keep an operational system running. This develops your ability to diagnose and fix problems. It teaches you about all the bizarre events that can happen in a real system that never seem to happen in testing. I personally found it humbling to watch systems I thought were solid get hammered and fail in ways I never expected. You will learn the value of many non-functional requirements such as reliability, performance, scalability, manageability, and supportability (e.g. good logging).
• Maintenance: Make enhancements and fixes to an existing code base in active use. You should do this both for a system you originally developed and one you have not. This teaches the importance of good design and readable code – i.e. maintainability.
• End-User Support: Directly dealing with user inquiries and problems. This is enlightening in numerous ways: it provides you with a better understanding of what users value, how they react, their level of understanding of I.T., and what they like and do not like in the software they are using.
• New Development: Develop a piece of software going through all the stages of the software development life cycle: inception, requirements, design, coding, testing, release, and maintenance. Going through the entire cycle gives you a deeper understanding of the big picture. More importantly, you will have the opportunity to benefit from feedback in later stages regarding earlier stages: e.g. coding indicates requirements were poorly understood by all, or testing reveals a design defect.

Optional Rotations

There are many other possible rotations across the full breadth of the field of software development. A large (but not complete) list of these assignments is provided below, organized into categories.

• Assignments in different types of software development organizations:
  • Product-focused
  • Service-focused (e.g. consulting)
  • Internal I.T.
• Assignments in different organizational cultures:
  • Bureaucratic
  • Entrepreneurial (e.g. a start-up)
  • Lean
• Assignments using different development methodologies:
  • Agile (process-light)
  • RUP (process-heavy)
  • Waterfall
  • Chaotic
• Assignments working on different types of software systems:
  • Web applications
  • Enterprise systems (e.g. messaging, batch processing, integration of systems)
  • Desktop
  • Mobile
  • Games
  • Software development tools (e.g. compilers, IDEs)
  • Software infrastructure (e.g. operating systems, databases, networking)
  • Scientific (e.g. simulations)
  • Mission critical (e.g. medical, aviation)
• Assignments involving different software development skills:
  • Web design (html, CSS)
  • User interface design
  • Database design
  • Database administration
  • Data conversion
  • Web services
  • Batch processing

Obviously you cannot gain experience in all of the items listed above. The point is to think about where you want to take your career as a software developer and then choose assignments that provide sufficient breadth while avoiding irrelevant assignments.

Adopting Rotations

How can rotations for software developers be adopted? As much as I think it makes sense, I do not see the I.T. industry as a whole formally adopting rotations in a fashion similar to medicine. So what about at the level of an individual organization? Even fairly small companies usually have different teams or products for which rotations could be formally set up. I have seen companies doing this for undesirable work such as customer support or production support. Developers are rotated into such roles either for an entire iteration or for a certain percentage of days each month. But the focus of these rotations is typically on getting the undesirable work done rather than the increased learning.

In many companies I have seen a tendency for developers to get stuck into a particular role or team. Supervisors are reluctant to give up a trained, skilled resource to another team, even in a trade. Temporary assignments on another team are also fairly rare for the same reasons plus the common fear by the supervisor that the temporary situation ends up becoming permanent. So a developer who wants a change often needs to initiate it by changing jobs.

Since the industry as a whole as well as individual organizations cannot be relied upon to provide for rotations, I believe it becomes the responsibility of each individual software developer to seek out that breadth of experience. Formal rotations may be beyond our control, but we can explicitly seek out different assignments to provide that breadth of experience and accelerated learning.

I'm interested in hearing what you think. Do you agree with my list of required rotations? Are there any you would add or remove? Do you have examples of where you actually used rotations? Let me know by leaving a comment below.

]]> http://www.basilv.com/psd/blog/2009/using-rotations-to-develop-expertise/feed 1 http://www.basilv.com/psd/blog/2009/the-core-skills-all-software-developers-need http://www.basilv.com/psd/blog/2009/the-core-skills-all-software-developers-need#comments Fri, 10 Apr 2009 17:37:33 +0000 Basil Vandegriend http://www.basilv.com/psd/?p=339 Software development spans a wide gamut of technologies (e.g. C, Java, and Ruby) and environments (e.g. embedded, desktop, enterprise, web, computing infrastructure, and scientific). Despite all the variation, I believe there are core software development skills that you must possess in order to be an effective developer across most, if not all, of these different scenarios.

More specifically, I believe that your level of ability as a software developer is in large part determined by your mastery of these core skills. Intermediate-level developers should have used all of these core skills and be competent in most of them. More junior developers will likely have gaps where they lack familiarity with some of these core skills and need to increase their competency with the others. Senior developers should have achieved mastery of most of these skills, be competent in using the remainder, and should be able to coach less experienced developers in the use of these core skills.

These core skills can be used both as an evaluation tool and as a professional development guide. Obviously these skills should be assessed in job interviews, but I also find it beneficial to assess developers joining the team, especially the more junior, and assign tasks and provide training opportunities based on this assessment.

The core skills needed by all software developers are:

Core Skill	Description
Read Code	The ability to understand an existing code base in order to analyze its behavior and make fixes or enhancements to it.
Write Code	This does not include any significant amount of design – just the basics of coding. An example is being able to write a method given the desired behavior (inputs, outputs, pre-conditions and post-conditions).
Design Software	The ability to determine what code is necessary to achieve some specified functionality, particularly the higher-level structure or organization of the code.
Awareness of the Software Development Life Cycle	This is an awareness of the 'big picture' of software development beyond just writing code - how the other life cycle stages (requirements, design, testing, and maintenance) impact coding and vice-versa. This includes an understanding of the types of methodologies (e.g. Agile or Waterfall) that can be used to progress through this cycle.
Use of Libraries and Frameworks	This skill could also be called "Reuse Existing Code". This skill includes the ability to search for and evaluate libraries and frameworks based on how effectively they meet your needs and the ability to integrate the chosen package into the software you are writing.
Debugging	The ability to analyze the behavior of code to diagnose a problem and find the underlying cause. This includes but is not limited to using a debugger.
Use of Integrated Development Environments	The ability to effectively use modern IDEs and an understanding of their strengths and weaknesses.
Use of Version Control	This skill includes basic use of a version control tool as well as a general understanding of software configuration management.
Automated Unit Testing	This is the ability to unit test code by writing automated tests.
Refactoring	The ability to revise existing code without impacting its functional behavior.
Use of Build Automation	This goes beyond simply writing a build script to include other related automation like continuous integration, automated deployments, and static code analysis tools.

I have deliberately excluded skills that are not specifically about software development. Some of these general skills are very important to software developers (as well as other professions) and are necessary in order to excel as a developer. Examples of such skills include the ability to communicate verbally and in writing, the ability to work well with others in a team setting, self-discipline, and personal organization.

I expect this list to be contentious. I may have missed a few skills you feel are core or may have included skills that you feel do not belong. Let me know via a comment below what skills you feel should or should not be core.

Update: I revised the description of the skill "Debugging" based on Jacob's comment below.

]]> http://www.basilv.com/psd/blog/2009/the-core-skills-all-software-developers-need/feed 16