Do you work with someone where it would be more beneficial for your team to have your company pay them to stay at home than come to work?  If so, you have a

Net Negative Programmer

Net Negative Programmers distract team members with long winded conversations, frequently commit bugs into your repository, ignore team coding standards, etc . . .

Google Tech Talks had a presentation titled "How Open Source Projects Survive Poisonous People."  Take a watch.  More to come on how to handle Net Negative Programmers.

What motivates you?

BTI is intensely focused on Advancing Collaboration through our 360° of Collaboration.  The most important element of the 360° is our PEOPLE

We are fanatical about hiring the best, most talented people.  Who are the best?  They are individuals that are strong technically AND strong interpersonally.  In other words, they can:

Talk to computers and also talk to people!

But having the right people isn't enough.  We need our team members to perform at their best, contributing to the maximum of their potential.

Recently, I watched a great animation of a talk given by Daniel Pink, author of Drive – The Surprising Truth About What Motivates Us.


Here is what I learned . . .

Motivation	Example
Self-directed	Atlassian: Give developers 24 hours to work on anything
Mastery	Linux and Apache power the infrastructure for thousounds of companies
Purpose	Steve Jobs: Make a "ding" in the universe

At BTI we provide an avenue for our team members to find purpose, mastery, and self-direction.

• We find purpose in our mission to Advance Collaboration.
• We find mastery in developing our technical skills.
• We find self-direction in leading and collaborating on our teams.

To learn more take a look at our Join Us page.

Now that we have the Value Stream defined the question becomes - What is the best way to process tasks through the value stream?

I've found typical Scrum projects tend to "optimize the part" over "optimize the whole."  So - what is a part?

Think of the Tour de France.  The Tour de France is broken into 20 stages.  Each stage has stage winners.  Than there is an entire tour winner. 

In this example, each stage is a "part."  When Lance Armstrong won his record 7 tours, did he focus on winning each stage or the entire tour?

Understanding the difference between optimizing for a stage and optimizing for the tour changes the strategy for winning.  Lets apply this to Kanban.

Typical Scrum teams tend to optimize parts of the system.  For example, developers will work really hard at coding the task and then 2 days before the end of a Sprint dump all their tasks on the Test Team. 

Here is what the Scrum board looks like:




I've seen this happen frequently on software projects.  In this case the developers optimized coding ALL their tasks before the end of the sprint, but the test team doesn't have enough time.  So the team optimized coding but not the entire process.

In this case the team got 100% of the tasks 80% done - but until something is complete there is no progress.  Kanban tries to fix this dilemma by getting something 100% done rather than many things 80% done.

How does Kanban accomplish this?  Through the following techniques:

• Minimize the Work in Process (WIP)
• Pulling Work

This will be discussed in following posts.

Speaker: MJ Wivell
Lecture: SCRUM - Building Trust through Regular Deliveries
Institution: Lynchburg College Computer Science department
Date: 4/2/10

MJ Wivell will be providing a lecture to the Computer Science department on "SCRUM - Building Trust through Regular Deliveries."

SCRUM is an agile software development methodology that breaks work down into manageable chunks and expects working software to be production ready after 2-4 week sprints.  SCRUM provides a framework for regular customer feedback through Sprint Planning and Sprint Review meetings. 

MJ is a Certified ScrumMaster with an expertise in the SCRUM and Kanban methodologies.

Recently a friend was boasting on the success that his company was having.  As I asked questions to understand what his company focused on and their area of expertise I realized that he had no idea.  But, he did say they have great food at their quarterly meetings.

Wow!  Here is a bright, loyal person who has no idea what his company does.  Yet, in his mind, they are achieving success.  How does he know his company is succeeding if his company does not keep score?

At BTI, we keep score so each team member knows whether we're winning or losing.   More importantly, each team member knows how BTI defines success and it is NOT simply putting a person on project and food at quarterly meetings.  BTI succeeds when the TEAM succeeds. 

In hockey the goals are tallied for the score.  In football touchdowns, field goals, extra points, and safeties are tallied for the score.  Well, BTI keeps score too.  So, how do we keep score?


Since we keep score, we know if we are winning.  How does my friend know if his company is succeeding if his company does not keep score?  They can't.  Because they are a body shop!  

Do you play for a winning team or does your company have you playing all alone?

With BTI’s focus on “Advancing Collaboration,” every once in a while CEO MJ Wivell would send me an instant message with the single question, “What are you going to do today to be more collaborative?”.

The first few times he asked this, I couldn’t come up with anything to respond with. I sat there staring at this question thinking: “What does it mean to be collaborative and how do I do it?” I pondered this question and slowly realized that I already do many things to advance collaboration on my project.

Collaboration is a mutually beneficial and well-defined relationship entered into by two or more organizations to achieve common goals.

The essential ingredient to collaboration is relationships. To advance collaboration means that we need to build relationships with the people we work with and our customers. Here are a few easy and practical ways to advance collaboration by building relationships on your project:

1. Start a technical book club with your co-workers.
Have each member recommend a book. After members have read a book, take time to discuss each book. The book club will help your team to learn new technologies and develop their skills together.

2. Go out with and invite your team members to lunch.
Make it a habit not to talk about work when you go out to lunch, this will help build relationships that aren’t solely based on work. Connect with people by learning who they are and things they enjoy.

3. Make a lunch run for your team.
Picking up lunch for your team members give those an opportunity who don’t have the time to go out for lunch a little change in their daily routine and a break from a bag lunch.

4. Help mentor a team member that may be struggling and not pulling their weight on your project.
Helping team members who are struggling on your project will increase productivity and help ensure that your team member will stay on your project.

5. Talk face to face with team members in your office instead of always using an instant messenger program.
In a world of technology we forget the power and need for face to face communication.

6. Compliment your team members when they do a good job and be sure to give credit for help you receive on work you complete.

Everyone feels good when they are recognized for their success. Recognizing the contributions of your team members not only improves their own opinion of themselves, but also greatly improves their opinion of and relationship with you.

As you can see collaboration is not that difficult. Many of you are already advancing collaboration in these and other ways. Collaboration takes time and effort, but it ultimately results in better relationships, better teams, and better products. You, your fellow team members, and your customers will all reap the benefits of successful collaboration.

At BTI, we believe software development is a team sport. Cultivate Collaboration – Drive Innovation!

In Part 1 of this series I explained reasons why my team searched for a Scrum alternative. In Part 2 we discussed how Kanban, a scrum alternative, provides visual indicators that trigger action. In Part 3 we will walk through the first step we took to moving from Scrum to Kanban.

Scrumban Level 1 Kanban is focused on delivering value. To deliver greater value, we must ONLY perform actions that add value to our end product – working, usable software.

In my experience, I have found that most developers on a software team have different understandings of the value added steps when working on a task. The typical Scrum board that I see on projects looks like the following: $0 Here’s the confusion – every team member has a different definition of “In Progress.” The steps taken during “In Progress” differ among team members, which causes confusion and frustration amongst the team. Some team members write unit tests, other do point and click testing. Some team members request code reviews, others do not. Some team members comment their code, others write a detailed specification. So what does it mean for work to be “In Progress???”

To answer this question we have stumbled upon the first step of going from Scrum to Kanban – Scrumban Level 1.

To define the value stream, we must ask ourselves two questions: What steps do we take that add value to our product? 

What steps do we perform that do NOT add value to our product?

Typically question #2 is the most important. A team must align around following practices that add value and flee from those that don’t. But agreeing upon the tasks that add value for YOUR TEAM is easier said then done. Because once you decide on these steps you must be disciplined, in fact FANATICAL in enforcing them. 

For example, most teams believe code reviews are important – but how many teams actually perform code reviews on a regular basis? Very Few! Why is this? Because when a sprint is about to end it’s convenient to skip over reviews. Just mark it done!

To remedy these problems, our team defined our value stream:
 Each step in the value stream must be defined with great clarity. Every team member must know what it means to complete each step in the value stream.

As you see, our first step is Specify. We believe it’s so important for our application to have strong documentation that we write the specification first. That way it does not get skipped over or done poorly. Next we Execute. We define this as testing and coding the application. Each team member is crystal clear on the expectations of what test cases must be written and passing for a task to be considered done. And finally, we Review our code. A team member is cannot move the task to Done until the code is reviewed. We believe requiring this step is critical to delivering a quality product. 

What are the “right” steps that define your value stream? That will differ from team to team. Different ideas on the software development process combined with varying skill sets means these steps must be tailored to your team. Your team may not need a high level of documentation – so don’t add this in your value stream! 

Just remember, once you’ve determined these VALUE ADDED steps – be fanatical executing them!  In your daily standup don’t allow a team member to move a task from one section to the next without an explanation of the work that’s been completed. 

BTI builds collaborative teams through the Practices arm of its 360° of Collaboration. The Practices arm is intensely focused in developing and applying practices such as Kanban to promote a working environment that is Highly Collaborative, yet Highly Efficient.

Do you have coworkers that fail to work as team players?  Do you work with other programs that fail to work well with your program? Time and time again I see coworkers and clients frustrated with team members and “partner” programs where communication breaks down.  

Oftentimes we blame poor interpersonal skills or a need for control.  But the root of the problem is much deeper.   Collaboration isn’t as simple as knowing how to communicate well and sharing information; it’s a way of working.

That’s the reason for the 360!  It takes people who know how to collaborate, practices that reinforce the collaborative nature, and technologies that provide a collaborative platform.  The 360°of Collaboration is a holistic approach to performing your job. Collaboration is a behavior, a lifestyle, a way of life.  A quick fix, Dale Carnegie seminar will not solve deep cultural habits.  We must live out a collaborative spirit in all areas of work life to create an environment where egos are nonexistent and through teamwork we achieve success.

Before applying Kanban to your development methodology we must understand the basics of Kanban. What is Kanban? Kanban is a Japanese word. Kan means visual. Ban means card or signal. Therefore, a Kanban is a visual indicator that triggers action. For example, a when you go to Starbucks to order coffee, the cashier marks a coffee cup with your order. The coffee cup along with the markings are a Kanban. Other Kanbans in our everyday life include stop signs, stop lights, alarm clocks, etc . . . The Kanban Board is a way to provide visual indicators that trigger action for software development team. As we continue with this series we'll see how the Kanban Board uses visual indicators to trigger action. BTI builds disciplined teams that advance collaboration.

Ruby Enterprise Edition version 1.8.7 has just been released you can download it here.

Check out this blog about an alternative to AutoTest called Watchr

Scrum has become the most widely accepted agile development methodology throughout industry. As it has gained popularity teams are analyzing the pros and cons of Scrum.

Scrum Process


With the help of Mary and Tom Poppendieck's Lean Software Development, my team has identified the following deficiencies in Scrum:
* WAITING
* PARTIALLY DONE WORK
* TASK SWITCHING
* EXTRA PROCESSES

1) WAITING
Our team had a two week development sprint ending on Thursdays. On the Wednesday prior to the sprint end date we would have a code freeze. Thursdays were used to test the code and Friday's were spent demoing the product and planning for the next sprint.

In theory this sounds great. But in practice I found software developers are not great testers. Developers found themselves sitting on their hands WASTING most of this time WAITING for new coding tasks.

2) PARTIALLY DONE WORK
Throughout each sprint our team would have many tasks in the "In Progress" section of our task board. Each task would be 80% done, but NONE of them would be 100% done.

3) TASK SWITCHING
Since we had a lot of work "In Progress" team members were constantly working multiple items at once. A lot of time was wasted while a developer would switch from one task to another. Each task switch required the developer to recall what the task inquired and re-learning the code during each switch.

4) EXTRA PROCESS
Each developer had a different definition of what it meant to be DONE. We found inconsistencies in the steps each developer took to complete a task. Some steps were not needed.


KANBAN
As we researched how to solve these issues we stumbled upon Kanban. Kanban is a lean software development methodology that helped us address the issues described above.

In subsequent posts I will describe Kanban in more detail and how we went from Scrum to Scrumban (a Scrum/Kanban hybrid) to Kanban.

BTI builds disciplined teams that advance collaboration.