Skip to main content

Scrum - Team Culture and Wall Manifesto


In the Scrum framework one of the key components is the wall and daily stand-up. In some organisations I worked with the whole concept of the wall is not accepted by many developers, because of the stand-up necessity and "time waste".

Very often all that methodology is used for the sake of methodology and not to achieve what we actually do - adding or creating value to our customer (usually called "The Business").

I can understand frustration that is caused by the wall and stand-up process. From the software developer perspective it is really a waste of time for the following reasons:

1. In 95% of cases developers are head down working like hell delivering valuable outcomes that they are accountable for. Extra effort to go to the wall, staying there for 15-30 minutes and listening or not listening to what others were doing yesterday and will be doing tomorrow is annoying for them;

2. The mere fact of having to do something mandatory to do that looks like useless activity is a strong demotivator;

3. In majority of cases the wall is a physical wall with the need to write on sheets of paper for the data already existing in some software system (duplication) and all the activity concentrating on multiplying redundant information and moving it on the wall. This process can be automated by using available tools, i.e. http://www.versionone.com/, https://www.atlassian.com/software/jira/agile, http://www.targetprocess.com etc. However many people still tend to use the real wall, not virtual.

It seems that contemporary IT specialists are driven much by the Scrum idea, therefore frustrations of software developers and other information workers should be somehow transformed into productive energy.

First step to achieve that is to create and discuss within a team a so-called Wall Manifesto – the declaration of the wall that will be used and purpose of it relevant to your team. The statements of the manifesto should define what your goals to achieve are and what problems or weaknesses you would like to overcome with it.

An example:

  • Quality outcome over output 
  • Efficient team over busy team 
  • Face to face conversation over email
  • Timely delivery over bottlenecks 

Happy scrumming!

Comments

Popular posts from this blog

Energy Business Case - Coal Mine in West Virginia

Situation Coal in Africa: An opportunity is available to invest in a coal mine in West Virginia. The mine’s value is less than in past years because of actual and anticipated restrictions on coal-fired power generation in the United States. However, the mine has a chance to sell its coal on contract to a public utility in West Africa. The utility is working through the World Bank for financing to build a number of coal-fired power plants. If they obtain World Bank financing, then a customer for the coal mine is assured, at least for the duration of the contracts. The power plants will employ the best current technology for burning coal, which exceeds all current air quality standards for the region. However, the power plants will not be designed to attempt carbon capture. The area of Africa the plants will serve suffers from extreme energy poverty, with some of the lowest per capita energy consumption in the world.

Overview of the Region West Africa is the westernmost region …

Wine - Castello del Poggio Moscato Provincia di Pavia

Awesome wine. Sweet with notes of pear, caramel, apricot.


Some details

Mastering The Multitasking

There is usually two distinct perspectives on multi-tasking:

1. Multitasking is counterproductive. We get distracted by multiple tasks that all get our way and fight for our scarce attention, time and resources. This leads to a common fallacy that if you do multiple activities “at a time” you are not doing good work in any of those.

2. Multitasking is a way of getting many things done in a short period of time or in a long run.

Indeed it can be either a disaster or a great helper depending on how it is used and practiced.

Most recent research shows that we don’t do multiple tasks purely in parallel or simultaneously. That means we don’t purely multi-task, but switch between tasks and execute them one at a time, but by spending very small timeframes on each task.

A good example from the history is a story about Julius Caesar capabilities in that area. Plutarch writes, “Caesar disciplined himself so far as to be able to dictate letters from on horseback, and to give directions to two w…