The Certified Scrum Master course doesn’t get offered very often in Calgary but as agile software development becomes more mainstream I am starting to see the course offered more and more. IMHO Scrum is quickly becoming the de facto standard for managing successful software projects today. Check out this course at http://www.scrumtraining.com/upcoming-events/ or http://www.scrumalliance.org/courses/2655-certified-scrummaster.  It’s a good introduction to agile project management using Scrum. Scrum is not technical at all since it concentrates on the management side of software projects. But when performed in conjunction with the technical software engineering practices of Extreme Programming, you’ll find they compliment each other very well.

I remember taking the course in the summer of 2005 with Kert Peterson and back then I think there were only around 3000 or so Certified Scrum Masters in the world. I think there’s at least 25,000 registered members now, here is the list of Scrum Masters (mind you not everyone here is practicing it though)http://www.scrumalliance.org/community/csms_only. You can also get trained in the Practitioner, Coach, or Trainer certifications as well.

This course is entry level (2 days only) so don’t expect to come out an expert. However, it does give you a good basis to start becoming an agile project manager. I would suggest this course not only to project managers, but project leaders, developers, product owners (although there’s a separate course just for PO’s now), and probably anyone in the software management domain who wants to know more about how to run an agile project.

You might be interested in this list of companies that claim to be practicing Scrum for project managing software projects. I say “claim to be” because it could be only a small team in the company that is practicing it, nevertheless some of these companies are very large so it shows how Scrum also scales to large organizations: http://scrumalliance.pbwiki.com/Firms-Using-Scrum

I finally got back to some reading after busy weeks moving offices and getting comfortable in the new  environment (I also changed employers!). This book was borrowed for an extended amount of time so I thought it was time to finish it and give it back or pass it on (thanks Mo)…

This is the Second Edition of the book where the author, Kent Beck, takes a lighter less “extreme” approach to introducing Extreme Programming. Still, if you don’t already know the values, principles and practices of Extreme Programming (XP), this book will help you question what you’re currently doing in software development and if it’s truly what you believe is the most humanistic approach. It’s not that this book tries to convince you on doing things a certain way, but rather, Kent Beck portrays values as universal truths then relates them software development through principles and practices that simply make sense. Values like communication, simplicity, feedback, courage, respect, … are some of the most important values of XP. Practices like co-located team members, visual informative workspace, pair programming, continuous integration, test-first programming, … are engineering practices that lead to better software. Then bringing everything together are principles like humanity, baby-steps, continuous improvement, mutual benefit, reflection, flow, quality, …  puts a software development context to the values and gives purpose to the practices that are being performed. All these work together and complement each other and without the values, principles, and practices as a whole the team lacks the true benefit of XP, actually I think it could lead to some very dangerous situations where XP could fail as an agile methodology. Other interesting points I noted in this book are:

• Identifying the highest priority user stories and building them first will yield the most business value and satisfaction for clients. It only takes 20% of the most important features to yield 80% of the business value (the 80/20 rule).
• Metrics in XP are different so be careful of how you measure it as compared to traditional business practices (you will get what you measure). Two suggested metrics are defect rate per deployment, and the elapsed time between the start of an investment idea and the time that idea starts generating revenue. I’ve witnessed many one week iterations with our team that demonstrates to our clients that given only a week we can turn their ideas into reality.
• The Theory of Constraints states that in a system there is one constraint at a time… find it… improve it or offload the workload or remove it entirely. Then move onto the next constraint and do the same.
• XP uses the “pull” model of developing software where stories are designed in detail right before they are implemented.
• More time at a desk does NOT equal increased productivity for creative work. Yes, software development is very creative!
• Plan for work based on past experience (your velocity in the last iteration), and adjust the plan when new information arrives.
• When faced with a big ball of mud (code design and complexity) begin by improving the design where you walk (lighting the lamp). Consistently performing small improvements is better than one big refractoring iteration where little or no business value is delivered at iteration-end.
• Members in an XP team share the same fate. Success and failures are shared amongst every member. The whole is truly more than the sum of it’s parts. Realizing the potential in software relies on teamwork. A deep change in values and relationships is encouraged.

Like everything in life, don’t expect a silver bullet to solve your problems or improve your situation. There is no prescription with steps that say “do this… then you’ll get exactly that…”, XP is something you should try then customize it to work for your organization. If it works then keep it and improve it, if it doesn’t work then figure out why and try something else. To me, at the end of the day, XP brings about an empowered software developer who continuously searches for better ways to improve business value. They are able to quickly estimate, implement, and deploy reliable software at incredible consistency. I leave you with a quote from the book:

“Tools and techniques change often, but they don’t change a lot. People, however, change slowly but deeply”

Agile is truly about simplicity and it is most apparent in the tools and practices our team uses everyday. Take our visual workspace for example, the place where high collaboration occurs on a daily basis. It doesn’t have to be a complex software package like some of the tools I’ve seen in the marketplace (I still have yet to try them all, but I do have a list and a reminder to try them out to see if they have potential). I find that once you put information in electronic format you have to do a lot of management (and reminding) to get people to read it. If you can get away with having it up front and center where everybody involved on the project can quickly and easily find out these 4 pieces of information, then you’ve got it made:

1. What’s planned for this iteration?

2. What’s done so far?

3. What’s remaining?

4. What’s the progress?

If a stranger can walk into the room without prior knowledge of the project, and within seconds know what tasks are complete, what tasks are remaining, and what the progress is… imagine the collaboration this environment would generate for the team and customers working on the project?

So how do you setup the simplest collaboration environment? Well, you don’t have to go to the “outer most reaches of Calgary” to find it, as Adam wrote in his blog. But you do have to put a little sweat into it! Trust me it’s well worth it if you need big custom boards and only want to spend a fraction of the cost. I’ve setup two offices (my old office and just last week my new office)using this environment and will probably do the same for my office at home. Here’s the details:

Whiteboard Purchase:

• You can go to your favourite home building/renovation store like Rona or Home Depot and look for 4×8 feet sheets of white Tileboard. This material is also called Melamine Tile. It’s typically used to build shower stalls, but the finish is basically the same as regular whiteboards found at office supplies stores. Make sure the surface is smooth and glossy (and bring a dry erase marker to test, I didn’t tell you to though). The board will run you about $72 each. You’ll need a truck (thanks Joel) with a 6 foot bed because these 4×8 sheets don’t bend very well.

Materials:

Counter clockwise from the top left of the first picture: 3 foot level, tape measure, hammer, two sided tape (holds down parts of the board that are not flush against the wall), Tim Hortons Timbits and coffee (mandatory), power screwdriver, wall anchor screws, screw head holders/covers, pencil, whiteboard marker (to test the surface), utility knife, drill bits and miscellaneous bits/screws.

Putting it up:

At least two people are required to put it up but with three it makes it even easier. You’ll need about 30-40 minutes for each board. Basically level it, put some pilot holes into the board and wall, drive in the anchor screws, place the screw head cover holder in, drill the screws until the back opens up and tightens, finish it off with screw head covers. There you have it, “the simplest collaboration environment” (I recommend putting at least one in each office, you can never have too many whiteboards). They look like this:

@ the old office:

@ the new office:

Usage:

Here’s a little more information on how to use your simplest collaboration environment from Mike Cohn: http://www.mountaingoatsoftware.com/task_boards. Instead of the typical index cards we use sticky post-its by 3M, not just the regular ones but the “Super Sticky” type (I think 3M made these especially for agile task boards). You don’t have to worry about tasks falling off the walls and getting lost. They actually work very well and you don’t need thumb tacks or magnets like with regular index cards.

That’s it!

This is the group photo during last weeks “Nothin But Agile Project Management” course March 3-6th at the Sheraton Eau Claire in Calgary, Alberta. From left to right: Rob from Petro Canada, Maria from Shaw, Me, Nina from CGI, Mark from Petro Canada, Kelly from Hatsize, Wendy from Petro Canada, Jason from IBM, and of course Jonathan the course instructor in front. The course was put on by Jonathan Rasmusson, an active participant in the agile community. Jonathan walked through an entire mock project “Bubble Battle” based on agile project management methodologies and best practices from inception to closing and hand-off. The course was an intense 4 days with workshops and group discussions on agile experiences both good and bad, as well as very important lessons learnt (which I love to hear about). View the rest of the pictures from the course at  http://www.flickr.com/photos/59259399@N00/sets/72157604097180657/. I highly recommend the course to new and existing project managers who want to know more about how agile works and what it looks like because soon I truly believe it won’t be called “Agile Project Management” anymore but instead just “Software Project Management”. Why you ask..? It works, it has proven itself to me, it makes the team happy, it makes clients happier, it reduces waste, it produces high business value software quickly, it continues to improve in whatever ways it can and will not be the same today as it was yesterday and it will be even better tomorrow… I can go on and on but I will stop now :-).

I’ve been practicing Scrum as an agile project management methodology for a while now and in the last year I’ve been lucky and able to implement many grass roots “pure” style methodologies. So, it led me to think “where did Scrum come from” (the software version not a scrum from the sport of Rugby) and what significance it has in influencing the software management/development community? What was it before the likes of DeGrace and Stahl referred to it in Wicked Problems, Righteous Solutions? What was it before Ken Schwaber and Jeff Sutherland used it in their companies then presented a whitepaper on the topic at OOPSLA’95? These questions lead me to this article “The New New Product Development Game” by Hirotaka Takeuchi and Ikujiro Nonaka. The article was published in a 1986 article of The Harvard Business Review. That struck my interest so I immediately ordered it from the original source. The article has this intro:

In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method – as in rugby, the ball gets passed within the team as it moves as a unit up the field.

The article goes onto identifying the 6 characteristics of the holistic approach to new product development.

1. Built-in instability – management sets challenging goals but doesn’t specify exact work plan.
2. Self-organizing project teams – autonomy, self-transcendence, and cross fertilization.
3. Overlapping development phases – Type B, Type C, sashimi, rhythm, and pulse.
4. Multi-learning – multi-level learning and multi-functional learning.
5. Subtle control- self control, group control, and control by love.
6. Organizational transfer of learning – transfer to other divisions and other new product development projects.

For more details you’ll have to read the article (ask me for hard copy). It also mentions many scenarios where the holistic approach to product development many not work such as; requiring constant team effort throughout the development process, scaling to large projects like those in the aerospace business, or in an environment where a genius makes the invention and hands down a well-defined set of specifications for people to follow (in software development AKA “code monkeys” who follow predefined design documents written by a master architect weeks/months prior).

Managerial behavioural changes also need to occur in order for the company to achieve high speed and flexibility. The article points out 3 things that need to change in a company:

1. Companies need to adopt a top management style that can promote the process.
2. A different kind of learning is required. From a depth-based individual learning (highly competent few) to breadth-first group learning across different levels of the organization.
3. Management should assign a different mission to new product development. Most companies treat new product development as a means for future revenue, but sometimes it should be a catalyst to bring about organizational change.

The article references projects from these large multinational companies like Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard. The original context was in the manufacturing industry but I found it really interesting that for such an old and very rigid process structured on Taylorism that the software industry (which is a lot newer) is behind in times when it comes to updating it’s process engineering methodologies. The manufacturing industry has revolutionized their processes, which is evident in the lean manufacturing principles of the Toyota Production System (TPS), while the software industry is only now (in the last few decades) starting to catch up!

I leave you with the last sentence from the article:

What we need today is constant innovation in a world of constant change

I thought this was very funny. No offences to the guys I work with but maybe this will get us thinking about making our own song so that people will know how we work, what we do and who we are? There’s one particular guy on the team that can actually play an instrument and is even in a band (they play live shows). Joel, I am talking about you! Maybe your band can help us create our own agile development rock song? Or a song about the benefits of test driven development? Ha Ha! Check out the song “Code Monkey” by Jonathan Coulton. You can find other songs found on his website: http://www.jonathancoulton.com/. I wonder if there’s original songs written specifically about agile software development…?

Don’t worry, I am not trying to change the English language! That comment is very true with the software development process that I believe in, practice, and communicate to the people that I work with to deliver business value (including customers). This statement by Kent Beck in “Extreme Programming Explained (Second Edition)” essentially means don’t try to make things 100% perfect, rather the action of perfecting something is more important. Most of the time the benefits and value to the business will be missed if we wait for perfection before we can start/deliver. Continual improvement or kaizen in building and delivering software means many things (taken from http://www.kaizenmanifesto.org/):

1. Make continuous improvements in every aspect of the business.
2. Actively pursue a superior, complete customer experience.
3. Continually improve designs, code, and processes.
4. Strive to increase agility (binshou) while reducing costs.
5. Use the Deming Cycle to minimize disruption from change.
6. Prevent errors (poka-yoke), in software and in business.
7. Respect people, leverage expertise, and trust staff.
8. Reward suggestions, improvements, and progress.
9. Always move forward.

So if you are looking for the perfect design, the perfect process, or the perfect software solution, you’ll be left behind while others are finding the benefits of a great solution today, knowing and understanding that tomorrow it will be even better. Make kaizen work for you today by not waiting for perfection!

Well it’s taken way too long to get this site up, but in the last 2 weeks I’ve worked with our website developer to get our Third Angle division site up. My role in this division is the agile project manager and we are the software development division of MediaLogic Group. The team is made up of very passionate developers and we are an Agile Software Development shop based in Calgary, Alberta. Look out, you’ll here more from us soon enough! I’ am looking forward to 2008 as some of our goals are to make an image for ourselves in the industry and spread our name in the agile community both in Calgary and beyond. The website will constantly be updated as we have a lot more content to add so please come back often.

I don’t know if there are better website statistics tools out there but Google Analytics is chock full of features and really simple to use/setup. Oh yeah… and it’s free! Looking around the internet there seems to be 3 ways of adding the Google Analytics tracking code to a Subtext blogging platform. So once you get your Subtext blog up and running, sign-up for a Google Analytics account which includes both free and paid services. Once you get your tracking code snippet from Google you can put it into your site using one of these methods:

1. Add it to the “Static News/Announcement” in the “Configure: Manage your blog” menu item when you are logged into the Subtext Admin.
2. Add it to the PageTemplate.ascx file which is the skin’s master page control. Look in the Skins directory under the skin your site is using.
3. Add it to the dtp.aspx page that is located at the root of your Subtext install.

I didn’t want to put it using the Static News/Announcements method because it was meant for something else and someday I may want to use that feature. Also method #1 put the code snippet at the top of the page before the post entries whereas Google’s suggestion is to put it at the bottom of the page before the </body> tag. Method #2 was a good option but if I want to change my skin to refresh my site’s look and feel I’d have to do the same thing on each skin that is loaded for my site. I ended up choosing method #3 because it placed the code a lot closer to where Google wants and if I want to change my sites skin I don’t have to edit the skin’s master page.

There’s also a new tracking code provided by Google (December 2007) called ga.js instead of the older soon to be legacy: urchin.js. I haven’t seen the reports  because I don’t have statistics yet but Google says there will be new advance features and sophisticated reporting, so upgrade your tracking codes!

Yesterday I attended a monthly user group meeting held at the University of Calgary by the Calgary Agile Methods User Group (CAMUG) . The presentation was put on by Jonathan Rasmusson, a well known active participant in the Agile community since 2000 (he’s also our Agile Mentor consultant at MediaLogic). Jonathan introduces an aspect of agile projects that is often underestimate as to it’s effectiveness if applied properly before the project begins. This concept Jonathan calls “The Agile Inception Deck” which basically lists 10 exercises you should do before starting any software project:

1. Remind ourselves why we are here? It’s good to set the stage. Ask the questions like why are we working on this project and why is this project is important to our stakeholders. The purpose will remind us of the goals and help us through the good times as well as the not-so good times.
2. Produce an elevator pitch. This gives a quick and to the point statement that all project stakeholders (anyone who has an interest or a gain upon the successful completion of this project) can collectively share and own. Jonathan refers to Geoffrey Moore’s “Crossing the Chasm” which entails filling in the following sentences: For (target customer) who are dissatisfied with (the current market alternative) the product is a (new product category) that provides (key problem-solving capability). Unlike, (the product alternative),we have assembled (whole product feature that makes it a compelling choice for the target customer).
3. Design a “cereal box” to sell your product. This exercise is about creating a shared understanding about the product and making sure that it highlights the Benefits of the product versus the Features it has. In this example a Feature of a family van would be 266 horsepower but the more important Benefit would be passing safely on the highway.
4. Create a Not List. Identify all things that this product is not. This helps scope down the product and makes less risky. For example, the product will help you do your taxes in record time but it is not an accounting system or the product or project will allow online PayPal payment processing but it is not a full blown e-commerce shopping cart.
5. Meet your neighbours. This exercise helps identify all groups that this project may be affecting, either directly or down the road. Identify and diagram organization contexts such as Business Operations, Business Information Systems, End-Users, Quality Assurance, etc. Introducing the project to many potential groups in the company increases areas for better collaboration as well reduces the likelihood that later on there’s a conflict with other company initiatives.
6. Map the terrain. This is best done using a system diagram identifying such entities as legacy systems, logical scope, integration points, internal and external systems, technical vision, etc. This helps to distinguish the systems that are and are not part of this project. It also shows some restrictions and constraints that the project must work within.
7. What keeps you up at night? Ask the big questions at up front because as the project progresses it will be harder to do so. Risks can be anything that may prevent the project from being completed successfully. The idea here is to record anything and everything that the team thinks could prevent the project from being successful. To me this means brainstorming all potential risks, then qualifying and quantifying likelihood and impact, ranking the risk in a matrix, coming up with counter measures for risks that require a mitigation strategy.
8. Size it up. This step helps set everyone’s expectations for what the general scope of the project will be and the high level expected completion date. To me this means looking at the product backlog, gathering epic stories, estimating high level story points, utilizing past team velocity, story prioritization, and an initial product burn down estimate. This helps the development team and product owner understand the general scope of the project as well allows for project resource allocation.
9. Clarify who’s calling the shots? Jonathan identifies one of the most important exercises of The Agile Inception Deck is to distinguish the management structure and clarify who has the last word from the customers side. Usually the smaller the number of people calling the shots the better. In Scrum this role is known as the Product Owner.
10. Trade-off sliders. If you have a project where the scope, cost, and schedule are all high priorities and there is no give in any one aspect then that’s a sign of a project that is dead before it’s begun. This reminds me of a quote from Mary and Tom Poppendieck in their book titled “Lean Software Development An Agile Toolkit” “Agile methods tell us that the customer cannot specify all four of the software development variables (cost, schedule, scope, quality).If the timeline and cost variables are fixed, then the scope of the work must be variable or the definition of the scope must be at a high level so the robustness of each feature can be negotiated…”. Produce a trade-off slider for the project including the 3 sliders scope, cost, and schedule (quality is non-negotiable). Add a couple more sliders based on project goals and work with the client to ensure that an evenly distributed trade-off slider is produced.

So the next time you start having project smells, think about The Agile Inception Deck and how it could have saved you a lot of headache (I will!). And promise to never start a new project without one.

During the presentation Jonathan brought up a well known prayer “The Serenity Prayer” that I thought was brilliant and very agile, the prayer goes:

“God, grant me the serenity to accept the things I cannot change; the courage to change the things I can; and the wisdom to know the difference.”