Skip to content

Companies

kanban and the perfect job

Dennis Stevens and Associates - Sun, 01/16/2011 - 22:55

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

This is the 5th principle behind the Agile Manifesto. The way this often gets translated is “take the top 10% of developers – put them in a room – and get out of their way.” This is great for the small groups of people that can build teams of entirely top 10% developers.  The question is, what do the other 90% of organizations do?

I believe this is a little chicken and egg. Do we build projects around motivated individuals – or can we design the work environment so that we end up with motivated individuals to build projects around? In the book, Understanding and Managing Organizational Behavior (George, J. M., and Jones, G.R. (2005). Understanding and managing organizational behavior, (4th ed.). Upper Saddle River, NJ: Prentice Hall.) there is a chapter entitled “Creating a Motivating Work Setting”. This chapter discusses the models and research associated with answering this question.

The Job Characteristics Model

In the 1970’s Richard Hackman and Greg Oldham attempted to identify which job characteristics contribute to intrinsically motivating work and what the consequences of these characteristics are. The thought process is that, when employees are intrinsically motivated, good performance makes them feel good – so they strive to achieve at a a high level and good performance becomes self-reinforcing.  Their model, called the job characteristics model, identifies five core dimensions that affect intrinsic motivation:

  • Skill Variety: The extent a job requires an employee to use a number of different skills, abilities, or talents.
  • Task Identify: The extent a job involves performing a whole piece of work from beginning to end.
  • Task Significance: The extent a job has an impact on the lives and work of other people in or out of the organization.
  • Autonomy: The degree a job allows an employee the freedom and independence to schedule work and decide how to carry it out.
  • Feedback: The extent performing a job provides an employee with clear information about his or her effectiveness.

There has been significant research done around this model. It turns out that jobs that are high in these characteristics have the psychological effect of increasing the experienced meaningfulness of work, increasing the experienced responsibility for work outcomes, and increasing the knowledge of results. In return, these psychological states have a high correlation with the job outcomes of high intrinsic motivation, higher job satisfaction, lower absenteeism and turnover, and higher job performance.

This is exactly what we want, highly motivated individuals to build projects around. While the psychological states and the job outcomes are emergent outcomes that we can’t cause directly, Hackman and Oldham have shown that when we design jobs based on the job characteristics model we can improve the likelihood these psychological states and the resulting desirable job outcomes with emerge.

The Motivating Potential of Kanban

When implemented well, Kanban creates a work setting where the job design delivers on the five core dimensions of the job characteristics model.

  • Skill Variety: In Kanban, the team members are involved in the daily planning of their work, engage in discussions around how to get the work done, perform their specific work, and may swarm on other related work.
  • Task Identity: In Kanban, the entire focus is on the flow of work. The team members see the work flow from start to end.
  • Task Significance: One of the focuses of Kanban is to improve the lives of the team members themselves.  The focus on flow of value also helps the team understand how they are improving the the work of the customer and/or the people their organization.
  • Autonomy: Kanban allows teams to schedule their work through the pull mechanism. The self-organizing nature of the work also helps them decide how to care it out.
  • Feedback: Managing Cycle Times, explicitly tracking defects, and the rapid feedback cycles associated with the limited WIP create feedback on effectiveness at multiple levels.

Kanban inherently results in job design that improves intrinsic motivation and the resulting high levels of performance.

Kanban and the Perfect Job

Hackman’s and Oldham’s job characteristic model provides insight into how the work environment can increase job performance. We tend to focus on the benefits that Kanban delivers by improving the flow of work. In addition to improving the mechanics of flow, Kanban also has the potential to result in job designs that are high in all five job characteristic domains.  These result in psychological states that correlate with desirable job outcomes including higher job performance. 

There is a risk in implementing Kanban that we end up focusing on just the mechanics associated with the flow of work. Forgetting that software development is knowledge work would be problematic. But, by leveraging the work environment of a Kanban implementation we can create an intrinsically motivating work environment. Combing improved flow with an intrinsically motivated work environment results in a much more productive organization. Focus on the human and work environment aspects along with the benefits of flow when we implement Kanban to create the perfect job for team members.

Categories: Companies

Standing By My Agile Claims

Dennis Stevens and Associates - Thu, 11/25/2010 - 17:27

I recently posted a presentation, Agile Foundations and Agile Myths, at www.slideshare.net/dennisstevens. My goal in the presentation is to juxtapose destructive behaviors arising from a predictive approach and destructive behaviors from an agile approach. This is a deliberately provocative presentation – finding flaws with the common interpretation of both sides of the discussion. Glen Alleman over at Herding Cats responded to my presentation in his post More Agile Claims. He took offense to my “strawman” arguments against the predictive approach.

Predictive Approach to Improving Software Development

What I am calling the Predictive Approach addresses the “mental scaffolding” or underlying assumptions I see everyday in companies practicing what they believe they are guided to do in the PMBOK®, OPM3®, CMMI and DoD . The Predictive Approach describes the practices that arise from the overzealous and misguided belief that the following approach is the best way to improve software delivery.

  • Standardize processes
  • Optimize resource utilization
  • Perform rigorous up-front design
  • Produce comprehensive documentation
  • Get up front commitment to a definitive Scope, Cost and Schedule
  • Enforce strict adherence to the detailed plan

This is where Glen takes offense. He points out that nowhere in the PMBOK®, OPM3®, CMMI or DoD literature are we instructed to apply these in the value destroying way that I discuss. In fact, he charges that I am just “making it up.” But, Glen misses the point. I am not arguing about the literature – I agree with Glen’s interpretation. And I am not making it up. Every day I go into companies that are applying this approach in value destroying ways. In the last year I have been in multiple companies whose documented methodologies prescribe:

  • linear-document driven "over the wall" process thinking
  • assigning resources to multiple projects
  • comprehensive upfront design with detailed documentation
  • commitment to definitive scope, cost, and schedule, and
  • strict adherence to precise start and stop dates for individual tasks

I am not debating the literature – it is an issue of practice. Glen suggests in our discussion in the comments to his post that even the government sometimes exhibits this value destroying behavior.  My points aren’t straw man arguments against the literature – they are attacking a common set of misguided underlying beliefs that the value destroying practices arise from.

In fact, the Agile Manifesto itself arose as a response to common practice – not as a set of new practices. As of the writing of the Agile Manifesto, the writers (and many others including Glen Alleman and myself) had been practicing software development in an “agile” way for a decade or longer. Read the agile manifesto as a response to value destroying practice that is trying to bring attention back to what is necessary to successfully deliver software projects.

The Agile Manifesto

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

Agile Approach to Improving Software Development

And now, … the rest of the story.

The Agile literature rails against too much planning, non-value added documentation, misguided change control, de-humanizing linear process, and layers of bureaucracy.  There is clear recognition in this faction that these are value destroying. But the overzealous and misguided application of these beliefs lead to the other common set of value destroying practices I frequently run into.

  • No Planning
  • No Documentation
  • No Estimating or Commitments
  • No Process
  • No PM, BA or QA

Again, I don’t see the core agile literature advising these practices either. Alistair Cockburn, Jim Highsmith, Mike Cohn, Jeff Sutherland and Kent Beck all prescribe effective practices that support appropriate and progressively elaborated planning, documentation, commitment, and process. They all support the roles of project management, business analysis, and quality assurance when they aid in managing complex products. So the second part of my presentation addresses these misguided practices and presents finding a responsible and situation specific approach to delivering software that focuses on responding to change, enhancing flow and delivering value to the customer.

The Core Discussion

Glen’s response highlights an interesting challenge. My suggestion that current project management practices are value destroying brought out a strong response against agile. I have had the same response from the agile community when I suggest that agile beliefs result in value destroying behavior. Businesses need to be able to make informed business decisions – so we need predictability and planning (Check out Glen’s immutable principles). At the same time we need to manage the work in a way that protects and optimizes value. What is missing in many organization’s is a way to have the responsible discussion exploring underlying assumptions. Companies need to finding ways to make the situation specific changes necessary to balance predictive planning and agile execution.

Categories: Companies

Good Project, Bad Project

Ative at Work - Wed, 08/11/2010 - 13:42
The secret to writing good automated tests is to be a good software designer.

It sounds trivial - but the sad fact is that more often than not the attempt to implement test automation falls due to poor software design where people are struggling with strong dependencies where you cannot test a single class or module without also configuring a whole environment of databases, webservices, populating whatever tables etc.

When the novice experiences this the natural, but incorrect reaction, is to write fewer and fewer tests at a higher and higher level of integration, the limit case being manual end-to-end integration testing through the GUI.

It is a symptom of bad software design, not automated testing being worthless.

In a good project the test suite does not need to be changed when external data changes. In a bad project, the test suite breaks when time passes or every time someone runs the end-of-month job to add interest to the accounts, or when the ticker price changes for a stock.

In a good project, only a few localized changes to tests and production code are needed as for a requirement change. In a bad project, there is impact analysis and lots of similar changes all over the code-base to accomplish this.

In a good project most of the code does not know from where it gets its data - in a bad project, even a simple interest calculation business rule knows about how to look up the database and the interest rate web service.

In a good project there is typically 1-2x as much test code as production code. In a bad project there is often 5x-25x as much production code as test code.

In a good project most tests exercise only a single class or a few functions. In a bad project every tests activates a code-path through many parts and tiers of the application.

In a good project most of the test code is asserting that things went as expected. In a bad project, most of the test code is setting up the environment to run the test.

In a good project there are tests at all levels of the application. In a bad project they are mostly through the UI and often even manual.

In a good project you can change the application without risk. In a bad project change is painful, infrequent, risky and requires executive sign-off.

In a good project you can deploy new code to production safely many times a day. In a bad project you only do it reluctantly every monthly or a few times a year.
Categories: Companies

Tweetable Code - Introducing Docjure for Succintly Reading and Writing Spreadsheets

Ative at Work - Fri, 07/30/2010 - 16:08

How would you like to be able to SMS or tweet your Excel data-crunching code?

With Docjure, it is possible:

(->> (load-workbook "spreadsheet.xlsx")
     (select-sheet "Price List")
     (select-columns {:A :name, :B :price}))

This reads the A and B columns from the Price List sheet in the spreadsheet.xlsx file into a list of maps where the a column has key :name and the B column has key :price.

I believe that is pretty good for code small enough to fit in an SMS.

Exporting your business data to spreadsheets for further analysis is just as easy:

;; Create a spreadsheet and save it
(let [wb (create-workbook "Price List"
                          [["Name" "Price"]
                           ["Foo Widget" 100]
                           ["Bar Widget" 200]])
      sheet (select-sheet "Price List" wb)
      header-row (first (row-seq sheet))]
  (do
    (set-row-style! header-row (create-cell-style! wb {:background :yellow,
                                                       :font {:bold true}}))
    (save-workbook! "spreadsheet.xlsx" wb)))

In just a few lines of code and you have exported the price list to a worksheet, complete with a yellow-background bold header line for extra style points.

In our business applications, bridging to Excel has provided huge benefits:

  • Users love it - having their data in Excel enables them to do much more than a static report that can only be changed by a software developer.
  • Developers love it - It eliminates a lot of tedious code for generating bespoke reports as we can easily export data into an Excel report template.
  • Project managers love it - using spreadsheets provides an easy to understand data exchange format and the flexibility to change reporting features quickly late in the project.
  • Sponsors love it - the project saves a lot of time and reduces training cost by leveraging an application the users already know.

As an inspiration, here are some of the things we have used it for:

  • Use Excel to calculate currency trading strategies - the traders calculate their currency trading strategies in Excel then import it into the trading system. They benefit from the flexibility of a powerful tool they already know and the trading system takes care of the technical details of the actual trades.
  • Exporting to Excel for bespoke analysis - would you like to check your currency trading record? Export all the information to Excel and the traders can slice-and-dice it easily with little or no technical assitance. This is much easier than setting up a reporting database for them to link to.
  • Using Excel sheets for content management to facilitate translation - translating an application to all the languages of an international enterprise was easy. Rather than using complex technical XML-files we made Excel sheets the data format for the application strings and had the subsidiaries add their translations to that. Then we put an adapter on the application to convert back and forth to XML-config files and RESX files used internally in the web and Silverlight parts of the application. The translators had a great experience, they had a familiar tool with spell checking and it reduced waste in the translation process by presenting a well-known easily accessible format.
  • Exporting to Excel for reporting - set up a spreadsheet template with a data sheet and some reports based on that, then populate it with data from your application. This allows the users to easily change or add reports with no change to the software application itself, thus dramatically reducing the turn-around time for new reports. 

We believe this is so great that we just have to share it:

Therefore, Docjure is free and open-source.

It is written in Clojure for the JVM. Get it at our GitHub page here: http://github.com/ative/docjure and be sure to follow our updates on Twitter: @ativedk (http://twitter.com/ativedk)

Categories: Companies

Psst...Scrumy has an API now

Scrumy Blog - Thu, 07/01/2010 - 07:00

It's a new month, and now there is a new Scrumy feature for Pro users: The Scrumy API. Pretty much anyone who has asked us if we have an API recently has already been directed to that page and has been able to access it, but now we're sharing our secrets with the world.

For the uninitiated, an API is an interface that we give to you in order to access the data that we've stored for you in a convenient way. Essentially, it allows you to write your own programs that interact with your Scrumy projects. If, for example, you wanted a big red button that moves all your unfinished tasks into the 'Done' column, you could build that yourself with a few clever API calls.

The Scrumy API is divided into two separate parts: REST and Webhooks.

The REST API allows you to get data from your projects in XML or JSON form using simple URLs. You can also manipulate your data by POSTing or PUTing data to those URLs. You can read all about it at the REST API documentation page.

Webhooks are very different. A Webhook is a URL for an application that you have running on your own server which receives data from us. This means that any time you create or change a task, for example, we will send a piece of data representing the change on your project to that URL. A simple thing you could do with this would be to send a tweet any time you finish a task. Read more at the Webhooks documentation page. Also, the demo is set up to use webhooks, but it works a bit differently than your projects. The demo will allow you to enter 5 webhooks, but none of them will be active for more than 5 minutes. So, if you just want to see how webhooks work, feel free to use the demo, but unless you want to be a jerk, use an empty slot. Then you have 5 minutes to test your heart out.

So those are the big updates for now. If you find errors while reading the apidocs or feel that you could clarify something, feel free to update the documentation. It's a wiki for a reason. If you have any other questions or comments, feel free to contact us at support@scrumy.com.

Categories: Companies