Stories in Pivotal Tracker have been given a serious upgrade. For the most part it’s all pretty self explanatory - the functionality you’re used to is all there, just in a format that’s more intuitive, user friendly and hopefully you’ll agree, more appealing. Our advice, play with it and then come back and read the rest of this post, especially if anything is confusing.

You’re back, so let’s continue!

One of the goals of Tracker has always been to make collaboration around your story backlog as easy as possible, so that your team spends less time managing your project and more of it actually building things. We think there’s room to make that not just easier, but more enjoyable, even fun! So to that end, great usability and user experience are major themes in our backlog for 2012, starting with this story redesign.

See below for all the highlights.

New Look and Feel

Like we said, stories look different, and are hopefully a lot easier to work with now. It's a complete redesign, with a color scheme that fits better with the rest of the Tracker UI, and that's intended to make the important information in a story stand out more - such as the story title, description, comments, code commits, and file attachments.

Besides visual appeal, we’re aiming to reduce clicks - for example, when creating a new story, it only takes one click to choose a story type or point estimate value. And, you can now start, finish, deliver, or accept/reject an expanded story with one click, with the familiar buttons.

Click to Copy ID and Story URL

We heard your feedback about having to scroll down in stories to find their IDs, to copy them to your commit messages (you are using the source commit integration, right?). So, we've moved the ID to the top of stories, and made it so that you can copy the ID to the clipboard with one click (on the ID button).

The same is true for the story URL, for when you need to send someone a link to the story. Just click the link button in the top left corner, and the story's full URL will be copied to the clipboard. Note - you’ll need Flash enabled in your browser for these to work. If you don’t have Flash, you’ll see the full URL on a separate line, so you can copy it the old way.

Less commonly used actions, including delete and view history, have been moved to the “More” menu, which is where we’ll be adding some other convenience actions soon.

File Attachments on Comments

One big change in this redesign is that files are now attached to stories as part of posting a comment, rather than as a separate list. This is because files are commonly uploaded and shared in the context of an on-going conversation, and it’s so much easier to refer to a file that’s actually part of that comment (e.g. “Here’s that icon”) rather than having to say “see the file named foo.gif at the bottom of the story”.

You can still drag and drop files from your desktop to stories, and entering an actual comment when adding files is optional - just drop your files on a story and close it.

View All Images and Comment Filtering

The truth is, thumbnails of mockups attached to a story can be indistinguishable from one another. Sometimes you just need to see them all full sized, on one page. Now, with just one click of the View All Images link above the Activity section, you can.

We’ve also made it easier to find what you need in a long-winded (all of it beautifully clear and vital) comment conversation - just use the filter dropdown menu at the top right of the Activity section to show just file attachments, just source commits, or all comments without commits.

Feedback

This redesign of stories is the first step in an on-going usability overhaul. We’ve got much more coming over the course of this year, but we’d like to incorporate your feedback at every step, so please let us know what you think so far, in the comments here or by email to tracker@pivotallabs.com.

We've got a major update of Pivotal Tracker planned for this weekend, which requires downtime while we run a fairly major database schema migration.

The update is planned for Saturday, Feb. 4, at 9:00 Pacific Standard Time (PST), or 17:00 UTC, and we expect it to take approximately one hour.

Apologies for the inconvenience, but we're hopeful that you'll like what we're rolling out!

For real time status updates, please follow @pivotaltracker on Twitter.

Introduction

Setting up Git can be intimidating, especially for those that are trying a version control system for the first time or moving from Subversion. It used to be the case that Git was a huge hassle to install and use on Windows. However, nowadays it's super easy to use Git on Windows either through Git Bash, if you're a fan of the command line, or if you prefer a graphical interface, through programs like TortoiseGit. Below we'll show you how to set everything up and connect it with Assembla.

Note: Below is a condensed version that doesnt show EVERY screenshot along the way. For the long version, click here.

Table of Contents

1. Download and Install Git for Windows
2. Download and Install TortoiseGit (Optional but recommended for first timers)
3. Generate SSH keys
4. Link SSH key with Assembla

Prerequisites

1. Assembla Git repository - sign up if you haven't already, it's totally free for standalone Git hosting.
2. A strong desire to install Git on Windows.
3. That's it, let's go!

1. Download and Install Git for Windows

To get things started, you'll need to download and install Git for Windows. You can download it here. If you're unsure of which one to choose, just go with the full installer. After downloading, run the installer.

 
If you have PuTTY/TortoiseSVN installed, you may see this screen, otherwise just ignore this. Regardless, use OpenSSH to make things easy. 
 

Download and Install TortoiseGit

This step is optional. If you are comfortable using the command line for interacting with Git, you do not need to install TortoiseGit.

Next up, let's download and install TortoiseGit.
 

We'll need to configure TortoiseGit - to do this, right click anywhere on your Desktop, select "TortoiseGit" and then "Settings."


Find "Git" and then click on "Config" from the menu on the left. Then fill in your Name and Email, making sure to use the same email that you used to sign up for Assembla.

Don't forget to click OK when you're done.
 


Great, now TortoiseGit is all set! Generate SSH keys

There's two ways to generate SSH keys:
  1. If you installed TortoiseGit, use the method directly below. 2. If you only installed Git on Windows and are not using TortiseGit, jump to the "Git Bash SSH Keys" section.

TortoiseGit SSH Keys

SSH creates a secure connection from your computer to Assembla, making sure that you are who you claim to be so that only authorized persons can commit to your repository. Assembla needs to know your public SSH key to make the secure connection, so let's fire up Puttygen to generate an SSH key pair.

Start -> Programs -> TortoiseGit -> Puttygen


In Puttygen, first click on the "Generate" button.


Next, you'll move your mouse around the big gray area under the progress bar to generate randomness for super security.


Once the key is generated, you should copy it onto your clipboard. You'll use this later to authenticate with Assembla.


Afterwards, choose a memorable password and confirm it. Don't forget your password!


Lastly, click on the "Save private key" button and save your private key somewhere you'll remember.

Git Bash SSH Keys If you did not install TortoiseGit, you're at the right place! If you did install TortoiseGit, follow the steps above and skip this section.

• Start up Git Bash: Start -> All Programs -> Git -> Git Bash
• On the command prompt, type in the following command substituting with the email you used to sign up for Assembla.
• When it asks you for the file, just hit Enter.
• Please note that you should definitely enter a passphrase; when you type, nothing will show up. This is normal, don't worry about it.

ssh-keygen -t rsa -C "me@email.com"

Use Notepad to open up the .ssh/id_rsa.pub file you just generated and copy the all of the contents of that file.

Link Your SSH key with Assembla Open up your Assembla profile which is where you'll paste the public key you just copied from the previous step. 
 
Click "Add Key" after you've pasted the key into the box. You should see something like the following picture below. If so, congratulations, you're done with this section!
  Create Something! Now the fun begins! Click here to learn how to clone your git repository, add files, commit, and push.  
Stuck? Need help? If you encounter difficulty with any of this, don't hesitate to contact Assembla support.

In Part 1 of this post I explained why it’s important for agile development teams to have distinct specialties – very similar to the way a jazz combo works together to create beautiful music. In this post I’ll continue my parallel and explain the value of maintaining these specialized roles within a small, cross-functional framework:

Continued from Part 1 …

And, of course, we also have the rest of the musicians who are like the testers and programmers in that they all have some specialization, perhaps the instrument they play, or the particular way in which they play.  For instance, in the Duke Ellington Orchestra, not only was Cat Anderson known for being a great trumpet player, but he was also known as a high-note specialist. If applied to the agile software development environment, not only are there specializations like programmer and tester, but there are also some folks who are best at User Interface, or at database work. There was never a rule that only Cat Anderson could play the high notes, or that he could only play certain notes. And there should never be a rule that only your “UI guy” can work in the UI. That would lead to a very thin team.  There would be no ability to build a depth of knowledge throughout the team.  Should a particular team member be unavailable, and the skill in which she specializes is required, the team is now hostage to her schedule.

There are many reasons why small groups are desirable. Members of a small combo are best able to work together and play off of each other’s strengths and weaknesses. They can react to changes that might come from the stage dynamics. Whereas many large bands require a hefty amount of coordination and very little room for improvisation, the small combo thrives on improvisation. Everyone adds what fits best, and the feedback from the audience is immediate. The energy builds – not just from each contribution, but also from the cumulative effect. The band doesn’t stop and argue when someone makes a change during a jam session. Band members pick up the new tempo and use this change to make the music better than ever before; the same thing happens in agile software. The team is able to communicate and work together. The different players are not going through some intermediary, but directly to each other. The energy, the pace and the quality of the product all come out through this tight, frequent interaction.

I’d like to take the next few weeks or even months to explore further how we can apply the lessons of our jazz brethren to the world of software development.  We can talk about ideas like how to be successful with duets (pair programming), or perhaps how to conduct a jam session.  Hopefully, this will spark some ideas that can build a strong understanding of how to work in our agile teams.  What other comparisons can we make?  What do we do when a small combo begins to grow into a large orchestra?  What might that mean to us?  The possibilities are endless.

So now picture this: The agile development team comes together for a planning meeting. The director establishes the tempo by identifying, with the help of the team, the velocity for the upcoming work. The product owner then lays down a groove, describing the melody and harmony of the iteration.  She does this by providing a depth of description and acceptance tests, which show not just what we will be doing, but how each story interacts with the others. Now the rest of the team picks up the melody as shown by how the programmers and testers pair up and work on stories together. The team’s energy builds as the code is tossed back and forth in short phrases. Each member employs his strengths, but helps to contribute to the overall outcome wherever he can. At the end of the iteration, the audience expresses their appreciation for another fantastic performance.  Now we can chill for a little while, enjoy our success and look forward to the next gig.

Do you enjoy Steve’s posts? Check out more on his personal blog: http://bit.ly/yOBqBn

After over a dozen years of training and coaching in multiple Agile methods, we've seen how useful it is not to be attached to any one of them. Knowing a variety of methods helps you match the method to the need at hand. It also helps in its implementation. And it gives you the breadth of experience required to keep you from becoming dogmatic. It is easy to forget that just because something...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

Whenever I use John Deere as an example of a fantastic Agile adoption, I always get looks of surprise. That’s quickly followed by an ‘a-ha’ moment when I share that today’s

From my visit to the test farm in Des Moines - note all of the hardware on top of the tractors

tractors are run by more lines of code than the early space shuttles. Yesterday, ComputerWorld published a great article about John Deere’s Agile adoption, characterized as a ‘big bang’ across their 800-person development organization within a year. It’s definitely worth the 5 minute read.

By 2050, there will be 9 billion people on the Earth.

In 50 years, the world population will require 100% more food. Seventy percent of that food is expected to come from efficiency-improving technology. John Deere considers these their user stories, and they strive to use technology to help solve these global problems. If the ComputerWorld article is worth 5 minutes of your time, then Chad Holdorf’s in-depth talk is worth every bit of 25 minutes to hear John Deere’s bigger vision and how they inspire teams to tackle it at John Deere.

You can work with John Deere too.

I’ve been honored to work with Tony Thelen, director of John Deere’s Intelligent Solutions Group, and Chad Holdorf, their Agile Coach, throughout this transformation. And I share their passion for connecting engineers to solve these potentially disastrous problems. I’d like nothing more than to see some smart folks go to work for John Deere.

With my son in a John Deere plow.

Tractors and Agile? Absolutely. I can’t think of a better example of how software is shaping the world we live in – every single day. Congratulations Tony and Chad and best of luck on your social mission.

Ryan Martens is founder and CTO of Rally Software, a hopeful Citizen Engineer and a recovering Entrepreneur-in-Residence at the Unreasonable Institute. You can follow him on Twitter @RallyOn.

<Adapted from my article in CM Crossroads article titled, “Making Beautiful Music Together”>

Have you ever watched a jazz combo? The performance starts with the leader counting off the rhythm, then stepping away. Then the drummer begins to lay down a beat. Even at this stage, the audience can feel a groove hit the room. Soon, the piano joins and adds both melody and harmony to the piece. Energy is flowing from the chords as the team starts to see and feel the direction of the piece. Now it’s time for the other instruments to join in the fun. A typical combo will have a couple of different instruments, maybe a sax and a trombone or some other combination. Whoever starts off will state the melodic theme for the song, although sometimes the whole group does this together. After that, everyone gets the chance to do a solo, in which they improvise on the main theme, key off of past experiences and apply their musical knowledge. It’s not uncommon for jazz musicians to jibe each other, making jokes and comments while they are playing. The energy in the room builds and builds as the musicians play together, sometimes one at a time, sometimes in tandem. When you watch a jazz combo really swinging, it can be hard to tell who his having more fun – the audience or the musicians.

This metaphor works quite well to understand what makes a small team desirable, and how to be successful with such a team.  In the agile software community, we have asserted over and over again that we need small, cross-functional teams. And yet, what really is cross-functional? Can cross-functional really work? The more traditional view of software creation involves the need for separate, functionally focused teams who are experts in their domain. The teams only interact as they are passing work items from one to the other. When development is done, the teams hand off work to test. Test will find defects and hand them back to development. And the dance continues in this light forever.  The jazz model demonstrates that this can, in fact, work.

In a jazz combo, each member of the team has a specialty. The members play individually, but often together  they create a tapestry of music that becomes much greater than the sum of the individual contributions. A small development team works best this way. We have some set of programmers, testers, documentation specialists and some representative of the business working together. Team members gain their energy from each other. They try new things and get feedback right away from anyone who wishes to listen and share.

The team members don’t need to just focus on their own areas either. A tester can very easily and effectively form a duet with a programmer. They will play off of each other with their ideas. The tester will write a test to express some piece of functionality that the software will have. Then the programmer will answer with the code that will cause the test to pass. So we write another test based on this back and forth interaction. In music this interaction is known as “call and answer,” and it is especially effective with the testing and programming cycle, as it provides a rapid, tight feedback loop.  Communication is instantaneous, allowing for more freedom of action. More often than not, a programmer will pair with another programmer. This duet is very effective and powerful as well.  The programmers can build off of each other’s knowledge; ideas that might “seem like a good idea at the time” are instantly reviewed by a peer.  This type of pairing turns code review from an intermittent, reactive process into a continuous, proactive activity, and should be embraced as often as possible.

Let’s explore some of the roles that are important in a development team. Usually there’s some sort of coach or leader. In the Scrum world, you might hear about the ScrumMaster. Each of these names is meant to describe someone who is both a part of, and to some extent outside of, the team itself; in a jazz combo, this is the director’s role. Not every combo has a director, but many do. Sometimes that director is part of the team, only directing long enough to initiate and introduce a number to the audience. In software development, the director represents the team to the stakeholders, and helps plan the meetings, stand-ups, and the like – essentially counting off the beat. If the rhythm seems to be getting lost, the director can help the team identify this fact and help with corrective actions.

A team also needs an individual who has the ability to identify what needs to be developed. In agile development, this role belongs to the product owner. Now consider a jazz combo’s basic rhythm section… The drummer lays out the shape of what is to develop; the bass takes this one step further, presenting the progression of chords that identify the order in which the chords (which make up the actual harmonies and melodies) will be played. Lastly, the piano comes in with the rich, fully realized chords. Accordingly, the product owner has to play all three roles of the rhythm section, explicitly: identifying the work to be done or the shape of the upcoming work. Ordering the work in order of priority sets the rhythm.  Elaborating the story in terms of acceptance criteria provides the chord structure. And lastly, the constant interaction with the team throughout the development cycle provides the fulfillment of the intention as laid down by the acceptance criteria previously mentioned.

In Part 2 of this post, I’ll talk about what other roles are integral to every agile development team and explain how keeping the teams small and cross-functional makes it easier to react to change.

The Gist of the Story We believe in Agile software development for teams. From small teams to a 4000 person development group, our clients have enjoyed success with Agile. They have been able to deliver more value to customers at a more sustainable pace and with greater employee satisfaction than ever they were before. That is what keeps us going. We believe in Agile in all its flavors:...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]

The Product Owner is both one of the most important roles in Scrum and often the most difficult to fill. In this post, I will explore a few aspects of successful product ownership that are often done poorly or not at all.
Manage Both the Big Vision and the Small Batches

Keeping a balance between the development of product qualities that will fulfill the business case and the tactical execution of low-level features is perhaps the most important skill possessed by a Product Owner. The difficulty in simultaneously doing both of these things well often leads to an actual split in the role, where a “Strategic” or “Chief” Product Owner focuses on the big picture, and the “Tactical” or “Proxy” Product Owner works with individual teams attending to the details of execution. Tools like story mapping, product trees and personas are commonly applied at the big picture level by Strategic POs, while sketches, wireframes, process flows and various collaborative modeling techniques are generally employed by Tactical POs to help teams better understand and execute the details.
Strategic product ownership is focused on garnering feedback and testing the project's assumptions at the vision and business case level, while tactical product ownership should align the whole team against small batches of work within sprints to ensure the best execution possible at the detailed level.
Test the Project’s Assumptions
Business cases are often presented as foregone conclusions: Build the features, and they will come. However, there is no shortage of failed and unloved products to prove that this is nonsense. Projects are built upon more or less educated guesses of what the market and stakeholders need and desire, and it is the Product Owner’s job to test and refine these assumptions, thereby guiding change through objective data.
Techniques such as customer development in the "Lean Startup" approach focus on stating your assumptions in such a way that they can be tested, and then using feedback from these tests to adjust the project’s focus. The simple process of coming up with metrics that represent the product’s desired qualities and impact areas also can be of tremendous help when attempting to balance diverse needs across disharmonious stakeholders, as it forces a focus on overall project needs rather than individual features. In essence, the why must precede the how.
Use the Whole Team
When Scrum was first formulated, a joke cast the “team” as committed “pigs” while the Product Owner (along with general stakeholders) was dubbed a merely involved “chicken.” This is an unfortunate place to draw the line, because these two roles work best as a tight-knit partnership. Scrum teams already play an active role in design and feature elaboration, and the best products come from fully engaged teams, not ones that simply wait for their orders or ones design in a vacuum.
Collaborative modeling techniques, where designs are created and refined by small groups rather than individuals, are common in such environments. Finding the right balance between giving the team a “final, approved” design to develop vs. involving them deeply in the design process itself isn’t automatic or consistent across teams, but it is the only way to maximize both the efficiencies so often touted in Agile methods with product innovation, effectiveness and quality.
I hope you've found this post useful. If you have any other questions about how to be an effective Scrum Product Owner, share them in the comments and I'll do my best to answer all of them in future posts.
Subscribe to RSS Feed

TestLodge recently announced their latest feature that allows Assembla users to link their accounts to TestLodge's test case management tools. This integration makes many essential software testing features available to Assembla users without having to manually enter data for their tests and bug tickets multiple times. TestLodge created this custom integration using Assembla's REST API.

This first iteration from TestLodge offers the following features:
 

• Automatically create tickets in Assembla in the background when a test fails. Each ticket includes a description and steps to replicate, along with the expected result and actual result.
• Optionally, choose who the Assembla ticket should be assigned to, and set the priority.
• Associate an Assembla project workspace with a TestLodge project.
• View a test report that provides links to all created tickets.

About TestLodge TestLodge is a relatively new hosted tool that is designed to be a lot simpler than the traditional test management software by providing only the essentials to get the job done well. The system focuses on helping you create your test plans, input your requirements, create and manage your test suites & cases, and allow you to easily perform multiple test runs & generate reports.
Special offer As an introductory offer, TestLodge is offering a 20% discount for a limited time to anyone who makes use of the new Assembla integration. Simply sign up for your TestLodge account, then email TestLodge about the discount within a week of signing up.

Firstly, I'd like to say thanks to everyone for the wonderful comments received in regards my writing. Frankly, I am flattered. I'd also like to apologize again for not writing more regularly. It seems like I just never get the time these days with my busy life. The scenario I want to specifically talk about today is as follows: You plan a Story into a sprint, let’s say an 8 point Story, but the team doesn’t get to finish the Story. How should you account for the Story Points in the current and subsequent Sprints? Let’s just say for explanation's... Jack Milunsky

Is it fair to call Quasimodo ugly?

Earlier this year, on the LinkedIn Agile and Lean Software discussion group, someone posted the question, “Is it fair or accurate to malign the waterfall process as is rote when people push agile and Scrum?”  The original question drew a lot of discussion, and then it seemed to die down.  All of a sudden it has reared its ugly head again, and really requires a more thorough response.

When I first saw the post, I laughed.  Here was a guy posting in the Agile and Lean Software group a question which implied that any negative talk about waterfall was “maligning” it.  Needless to say, the wording implied an assumed answer.  My first thought was that this guy was a troll. And the usual folks would quickly send him on his way with scorn and derision.

What surprised me, and somewhat delighted me, was how many people replied with thoughtful discussion.  Folks took the question, wording and all, seriously.  They started to explore the question of whether agile had become dogmatic, or perhaps we were being unfair to waterfall.  The conversation was going to help everyone better understand why the world is moving to a better way of creating software, which is what we are calling agile (and now also Lean).  This is, after all, what discussion groups do so well.  We learned so much through the discussion groups in the early days of agile, as if we were our own Socratic society.

I quickly became disillusioned though.  The discussion was not a serious examination of the pitfalls of the processes known as waterfall management, and how to overcome them by moving to agile development.  Nor was it an open conversation on why – when it comes to software development projects -waterfall is the poorest of choices.  Instead, we saw a lot of folks very nicely saying that waterfall management will work just fine if you have all of the information up front… or if you have a very clearly defined set of goals and a strong understanding of the problem domain.  This would lead one to say, “gee, if that’s all it takes, why learn all these new processes?  Maybe we should just put a lot of time and energy into being able to get all the information up front, or into making sure we have a clearly defined set of goals and ensure they just don’t change during the project?”  Well I’ll tell you why.

***It just doesn’t work!***

This is a good time to remember why agile software practices came into being in the first place.  We didn’t all sit down and say, “You know, everything is going so well and projects are really coming in on time/budget, with high-quality code.  Let’s change everything.”

This all started because folks realized that projects were failing more often than succeeding.  Most of the projects that were considered success on the outside were the result of long hours and dangerous shortcuts.  Change became something to resist, even if the change was the right thing to do.

We spent a lot of time and energy trying to find ways to change this; we usually exhausted time and energy that would have been better spent creating software.  Agile development is about recognizing the difficulties and complexities of the software world, accepting them and working in a way that harnesses the ability to change software at a minimal cost.

So no, everyone doesn’t get a trophy.  Waterfall is not a good way to approach software projects.  That’s ok.  There are many non-software projects that would do quite well in the waterfall model.

Meanwhile, let’s dedicate ourselves to spending this coming year getting the most out of agile, especially finding the time to improve the craft of creating the software. Arguing about whether waterfall is still good is *so* 2011!

In a month we will run our third internal conference. This is supposed to be a full-day event, with one-of-a-kind sessions prepared and presented by our team members.

Here is the program:

Below are the updated overview videos for Assembla's most used collaboration tools - Wiki, Files, and Messages. If you are not taking advantage of any of these tools, you can add them to your project workspace in seconds from the Admin tab of of you space.

  The Wiki tool is ideal for organizing pages for instructions, ideas, specifications, documentation, and anything else you want. Add new pages in seconds, and customize the navigation to fit your needs. Let other team members contribute; if you don't like their additions, just roll back to any previous version.      The Files tool provides a central and secure place or organize and manage project files and Google docs. You can add files and Google docs directly to the Files tool or you can upload them to tickets, messages, wiki pages, etc. - either way, all your project files will be organized and searchable from the Files tool.       The Message tool lets team members communicate with each other while maintaining a centralized record of all conversations. Messages are a great way to facilitate communication and collaboration without messy email threads that get overlooked, clutter email inboxes, or don't reach everyone.

These videos and others can be found on Assembla's YouTube channel. 

We have updated our Ticket tool overview video to ensure that you and your team get the most from this powerful tool. 

This updated video was the result of a conversation with an Assembla user that said "the ticket tool is great, but I wish we could customize the workflows," not knowing that this can easily be done from the ticket settings page. Several other times, I have talked to users that were unaware of the Cardwall and/or Planner views. So even if your a seasoned veteran, take a few minutes to watch the video below - you may learn a thing or two. 

This video and others can be found on Assembla's YouTube channel. 

I recently left my Product Manager role at Assembla to become the Chief Experience Officer.  I transfered responsibility for a lot of different decisions about the product, release schedules, teams interactions and development. To make the transition easier, I decided to write a small piece of skills that the next Product Manager should have to continue running our product successfully. I knew that if he was the right person, he would not read a long piece of text about "managing" nor he will take my advice too seriously.

So I started with the great blog post from Andy about Assembla's Tech Lead Checklist as my base and together, we figured out which 5 Skills we were looking to have the best Tech Lead in the world to run our product:

1) Development You should be a developer, and a good one. Try to always make you some time to be involved with the code. If you help developers with their code issues, they will be willing to help you with the release. If there is an urgent problem that you can fix faster, do it. Don't forget that you started in these business because you wanted to program computers. 2) Release Management Your main job is to resolve needs and roadblocks (not to make sure that people are following any methodology). You should care to keep everyone moving and working on important and small tasks. Balance load so that everyone is only working on one task at a time. You should be good splitting work into small pieces so that the tasks are easier to estimate, control, finish or postpone when needed. 3) Product Management Prioritize, that's all. Then, you just have to work on the most important tasks from your list (which will also be small ones if you did your homework). Find "minimum releasable features" and products. You should think features as products and always be releasing features you can sell, otherwise you are wasting everyone's time. After you release a new feature, market it and continue improving it with user's feedback. Learn to let data drive your development by always defining metrics for your problems and to prove your solutions. 
Aside:  If you follow these rules, you will avoid code refactoring.  You will only be doing refactoring when you need it for something new.  This is one of the ways that you will start to think differently from an pure engineer that is not thinking about product management. 4) Recruiting Learn how to test people inside your team. Don't waste time with paper work, leave that for someone else. Document the "getting started" and learn to do "on boarding" to help new members get started. You are seeking for people that get things done, the rest is just accessories. 5) Managing People Be honest and helpful. Always remember you might be dealing with people from different cultures and countries so understand the communication problems instead of getting angry about them. Your goal is to remove the stress away from your team but still make them part of the decisions and success so that they are happy and challenged. The hardest challenge is not to build a great product, but to have a growing team of talented and motivated guys working on the same thing. At the end, we took these ideas into a training program for our team members. We made some extra materials that best describe these skills and put them into practice. We will continue sharing it through our blog.

I like to participate in discussion groups.  I enjoy the discussions themselves, and I also like “meeting” the folks who are participating.  There are a lot of questions that get repeated in those groups, but I personally feel that the conversations are various enough that this is a good thing.   There is always enough of a twist on each one that I learn something new.

One question that comes up a lot is, “Who should be the Scrum Master?”  Sometimes it is as simple as, “Hey, we are starting to do Scrum, so we need a Scrum Master. Who should we get?” Sometimes it’s a bit more involved.  Many of these conversations really focus on turning Project Managers into Scrum Masters, as a sort of natural step in transitioning to a Scrum Team environment.  While I understand this seems to be a convenient, comfortable step, I’m not sure it is as helpful as it originally appears.  In our never-ending search for metaphors to explain ourselves, I am going to utilize that well known show from the ’70s and ’80s, M*A*S*H.

Consider the role of the Project Manager.  A good Project Manager is responsible for making sure all the variables for a project are identified and categorized.  He/she is also responsible for identifying and mitigating all of the risks in a project.  Most of this is done at the beginning of a project, and will then continue in a reactive manner throughout the course of the project.  Other tasks that are important to a Project Manager are to identify and manage the budget for a project, as well as make decisions along the way as to changes and delivery.  To me, this is Colonel Potter, as played by the late great Harry Morgan.

Col. Potter understood that his job was not to tell the surgeons what to do, or how to fix a wounded soldier.  He was absolutely a figure of authority, but knew when to get involved and when to stay out of it. When push came to shove, if there was a decision that the team wouldn’t or couldn’t make on their own, he was there to either offer some insight to help them come to a decision, or in some cases he knew he had to be the one to make that decision.  One disclaimer here:  the level of authority for a wartime military commander is going to be much higher than in our world, but much of this still applies.  Leadership is not really different; it just becomes that much more imperative.

So in the M*A*S*H series, who represented the Scrum Master?  I see the epitome of a Scrum Master as Radar O’Reilly.  He made sure everything got done.  People got used to relying on him without asking for something in particular, and he really made everything happen.  If something got in someone’s way, he knew what to trade -and with whom – to make that obstacle go away.  I also think it’s worth noting that Radar was a Corporal for most of the series.  He led from a position of no power whatsoever.  He knew nothing about surgery, nothing about the military, but everything about relationships (albeit, not the romantic kind). There was never any doubt as to who really made things happen there; it was all Radar.  He made things run smoothly so the doctors and nurses could focus on healing the sick and wounded.  This is the Scrum Master.

One last comment on the M*A*S*H analogy.  At the beginning of the series, the doctors did all of the surgery and the nurses supported them.  Over the course of the series, you would hear surgeons use statements like, “OK, nurse, close for me.”  Then later, the nurses started doing triage (determining which patients had to be operated on right away and which could wait) and, in some cases, even getting involved in the actual surgery itself.  So while everyone kept their specializations, each was able to branch out and help wherever necessary.

Sound familiar?

 

At Pivotal Labs, 2011 was an amazing year. And we want you to help us make 2012 even better. We're currently hiring for the following positions across our San Francisco, New York City, Boulder, Denver and Singapore campuses:

• Software Engineer - Mobile
• Software Engineer - Web
• Software Engineer - Tracker
• Sr. Software Engineer

Want to know more? Click here for full job descriptions, and to apply.

At Pivotal Labs, 2011 was an amazing year. And we want you to help us make 2012 even better. We're currently hiring for the following positions across our San Francisco, New York City, Boulder, Denver and Singapore campuses:

• Software Engineer - Mobile
• Software Engineer - Web
• Software Engineer - Tracker
• Sr. Software Engineer

Want to know more? Click here for full job descriptions, and to apply.

In the first part of this post we established a context about Kanban as an agile software tool (not to be confused with the manufacturing term, kanban).  I also explored some of the key myths and hype behind Kanban vs Scrum.  Now I’ll discuss the realities of implementing Kanban and some of the fundamentals that hold back both Kanban and Scrum implementations.

On paper, Kanban is certainly easier to kick-start from a change management perspective because you can leave current roles and processes largely intact; you just need to get commitment from the business to adhere to three basic principles:

1. Provide a high degree of visibility/transparency of the state of all work queued and in progress
2. Establish and respect WIP limits in the value flow
3. Commit to execution in a ‘pull-based’ manner from the prioritized work queue

Yeah, just get commitment and practice of these three things… Much easier said than done in my experience because they are frequently outside the circle of influence of those driving the change to implementing Kanban!

Usually it isn’t that the agile software teams are unable to execute under Scrum; the fundamental issue is that the business isn’t willing to accept a “pull-based” execution model  (required for Kanban and Scrum).

Businesses continue to make irresponsible commitments to customers and investors. This only perpetuates crystal-ball thinking, fixed-date, fixed-scope and fixed-cost projects. It’s the classic sales-driven model we see all too often where the sales arm doesn’t respect the capability of its product development group to produce predictable value for the customer in a timely manner, and with an agreed-upon level of quality. After all, quality is a business decision.

This irresponsible action ends up causing organizations to be unpredictable in their delivery, have lower quality, and to burn out their teams.  These outcomes in turn destroy brands, ruin company reputations on Wall Street,  increase the percentage of each investor dollar serving up technical debt (in lieu of adding new value to products), and causes instability in the organization’s systems due to turnover.

Bottom line, if an organization can’t make the commitment to respect their product development system’s proven delivery capability at the current level, neither Kanban nor Scrum will provide predictability.  But even in the face of this dysfunction, agile methodologies like Kanban and Scrum can still provide faster learning to teams, which allows them to test their assumptions faster and provide more value to their customers by delivering what they actually need.

In conclusion, I leave you with this advice:  ignore the myths and hype about Kanban. Before you can make any decisions on the Kanban vs Scrum debate, you must first evaluate:

• Your organization’s product development and sales culture,
• The nature of the demand for service from product development,
• The competency of your organization to plan and execute change, and
• The degree to which you’re willing to face the truth

Only then can you choose the best agile software tool for the job.

Related topic: What is Kanban? How is Kanban different from Scrum?