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.

After learning the basics regarding REST and RESTful URIs Topher decided he was ready to learn more about HTTP requests.  One of the important characteristics of a RESTful Web Service is the use of a Uniform Interface in which it uses the four HTTP methods in a way consistent with their definition. These methods are classified as either safe, idempotent, or neither.  A method classified as safe is a method that is intended only for information retrieval and should not change the state of any resource on the server. In other words a safe request should be free from any side effects . A method classified as idempotent means that multiple or n identical requests should have the same effect as a single request.

Let's look more closely at these types of requests.

Method	Intended Use	Safe	Idempotent
GET	To retrieve a resource	Yes	Yes
POST	To create a resource	No	No
PUT	To change the state of or update a resource	No	Yes
DELETE	To remove or delete a resource	No	Yes

GET

The GET request is used by the client to retrieve a resource or execute a query that will allow the server to retrieve a set of matching resources.  A GET request should be free of side effects, meaning it does not change the state of any resource on the server.

A GET request URI looks like

GET http://www.bti360.com/dictionary/set
GET http://www.bti360.com/dictionary?synonym=happy


The first URI is a URI for the definition of set. This request will return the resource with "set" as the identifier. The second URI is a URI for a query for words in the dictionary that are synonyms for happy.  This request may return multiple resources such as "content, joyful, chipper, peppy" and the resources are returned to the client in the Response Body.

POST

The POST request is used to create a resource on the server.  A POST request URI looks like

POST http://www.bti360.com/dictionary

This URI looks very similar to the GET URI except that it contains no resource identifiers or a query string.  Dictionary is the parent resource and a resource create with this POST request will be stored as a child resource of dictionary. With a POST request the data describing the resource is sent along with the request in something called the Request Body.  A POST is neither safe nor idempotent because by definition the request creates a resource on the server, and multiple requests could create multiple resources.

PUT

The PUT request is used to update or modify a resource on the server.  A PUT request URI looks like

PUT http://www.bti360.com/dictionary/set

You may be thinking "well that looks very similar to a POST request" and you would be right. The PUT request looks identical to the POST request with one main difference.  With a POST request the server generates a unique identifier for the new resource and for a PUT the unique identifier is already generated and known by the client.  If the client was allowed to generate the id then there would be no guarantee that the id was unique.

DELETE

The DELETE request is used to delete or remove a resource from the server.  A DELETE request URI looks like

DELETE http://www.bti360.com/dictionary/set

This requests that the server delete the resource identified by this URI, so it would delete "set" from the dictionary.

Safe and Idempotent Methods

There is one more final key point about safe and idempotent methods. These methods are defined to have these qualities in the HTTP/1.1 Spec and the client expects these methods to behave this way. But the server is not technically limited by this so it is up to the developer to ensure that the server software also follows these rules.

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!

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.