The Blog
New Scrum certificates
published February 4, 2011
I added Certified Scrum Product owner and Professional Scrum Master I under my belt. Although a certificate does not guarantee that a person actually knows how to do things in practice, it still provides some information on what that person values and that he/she is pushing himself/herself forward. Most beneficial “gems” that I have discovered while studying have been “you don’t know that you don’t know” type of things. Anyways, PSM I test is something that you should consider, at least take a free open assessment.
Utilizing thinking styles in Scrum development
published January 24, 2011
Should all team members participate in all tasks that the team is doing? Scrum advocates cross-functionality but does that mean that everyone should partake in every task? In short, team culture should encourage for teamwork and everyone should have a possibility to influence decisions but in practice it will be good if some specialization occurs. Why? Read on.
Our ultimate goal is to enable self-organization on a team. A team should work like a start-up company (read “The new new Product Development Game”) that self-organizes around a problem and decides how to solve it. In Thinking Styles book, Robert J. Sternberg presents interesting insights about what kinds of tasks actually motivate people. It turns out that people have preferences for specific types of tasks and teams should utilize this information.
What are thinking styles?
A style is a preferred way of thinking. It is not an ability, but rather how we use the abilities we have. We do not have a style, but rather a profile of styles. People may be practically identical in their abilities and yet have very different styles.
People with different thinking styles will, according to Sternberg, prefer working with different kinds of tasks. Also, this difference gives an advantage for a person whose thinking style suits better with a situation at hand. A developer with more “legislative” style will enjoy design work while a developer with a “judical” style finds analytical work more rewarding.
Thinking style profile is constructed from five categories: Function, form, level, scope, and leaning. These categories form a profile for a person that consists, among other things, of preference for design or executive work, motivation by single or multiple goals, big picture vs. detail orientation, and playing by rules or going beyond rules. For a real description, read the book.
Back to Scrum. I think that in ideal world, everyone should be doing tasks that are best suited for their profile and that they enjoy the most. Of course it does not mean that if nobody likes a task, it will not be made. Also, a team should be cross-functional and members should learn new skills outside their comfort zone. But if entire team is playing to their strengths it will increase work motivation and increase product quality. This is actually what self-organization is all about, people volunteering for tasks.
Nice subject for a retrospective
If a team is aware of others thinking styles it can self-organize more effectively. Therefore, if you don’t know what are the thinking styles in your Scrum team find that out in a retrospective, it will make a nice subject.
Driving a Scrum team at the edge of chaos
published December 12, 2010
Recently I have tried to understand chaos theory and complex adaptive systems and how those relate to Scrum teams. Especially, I am interested in the “edge of chaos” concept and how that applies to my work. There are sources like this and this, claiming that team of people are very creative at the edge of chaos. When I tried to understand what this really means, I had to start from the Agreement and Certainty Matrix.
The Agreement and Certainty Matrix
Also known as the “Stacey matrix”, is a management tool by Ralph Stacey for leaders to get guidance on how to manage people’s work depending on a problem’s complexity and team’s agreement levels.
Close to certainty
Issues or decisions are close to certainty when cause and effect linkages can be determined. This is usually the case when a very similar issue or decision has been made in the past. One can then extrapolate from past experience to predict the outcome of an action with a good degree of certainty.
Far from certainty
At the other end of the certainty continuum are decisions that are far from certainty. These situations are often unique or at least new to the decision makers. The cause and effect linkages are not clear. Extrapolating from past experience is not a good method to predict outcomes in the far from certainty range.
Agreement
The vertical axis measures the level of agreement about an issue or decision within the group, team or organization. As you would expect, the management or leadership function varies depending on the level of agreement surrounding an issue.
In IT world, If we are building a new solution with a technology that is new to developers we are moving from left to right in the matrix. When team does not agree on how technology should be applied, movement is upwards in the matrix. So far this makes sense. If we have challenges on only one area, project tends to be complicated but when both areas are challenging, we are working with a complex problem. Scrum was especially designed to deal with complex problems, where plan-driven approach will not produce best results. In the real world there are no clear boundaries like: “Aha, we just moved into the complex zone, better get us some Scrum”. Even though plan-driven works on simple projects, I think that also they benefit from agile execution.
People are most creative at the edge of chaos
Is this really true? According to excellent book “Group genius“, author claims that a lone genius is a myth and many (if not all) great inventions are a result from collective creativity and cannot be traced back to only one individual. I bet you have seen this personally as well. One person says something, a second one adds a thought, and a third person rephrases the idea. Suddenly a new concept emerges, which is a result from teamwork thus making the team more than a sum of it’s parts. But must all this happen at the edge of chaos and what does that even mean?
At the edge of chaos
Group genius states that collective creativity is the source of great inventions and thus we will need a team to come up with most creative solutions. On the other hand, Stacey matrix states that technology must be challenging and people must disagree if we are working near chaos. This makes sense, as team that always agrees might suffer from groupthink. The scale of Stacey matrix must also be team and situation dependent, as “technologically challenging” depends on the skill level of a team.
Joseph Campbell defines edge of chaos like this:
the edge of chaos is a place where there is enough innovation to keep a living system vibrant, and enough stability to keep it from collapsing into anarchy.
Michael Crighton (In the lost world) like this:
It [the edge of chaos] is a zone of conflict and upheaval, where the old and the new are constantly at war. Finding the balance point must be a delicate matter – if a living system drifts too close, it risks falling over into incoherence and dissolution; but if the system moves too far away from the edge, it becomes rigid, frozen, totalitarian. Both conditions lead to extinction. Too much change is as destructive as too little. Only at the edge of chaos can complex systems flourish. . . And, by implication, extinction is the inevitable result of one or the other strategy – too much change, or too little
If we define a state in which we will not make any progress because “everyone is doing their own thing” as “chaos” then we might have us a setting that can describe “the edge of chaos” in practice. To find out the actual border between chaos and the edge, we must face a situation where we feel that the work is not progressing and stagnation happens. When the team begins to stall because of the disorder, we know that chaos state is reached and some order must be restored to regain momentum. Are you with me?
How to increase chaos in a team
Why would you want to do that? To increase team’s creativity and to energize it to move away from it’s comfort zone.
- Come up with a new point of view and encourage team to discuss why current solution will (or will not) work.
- Facilitate discussions so that also introverts are heard. More insights more chaos.
- Ask team how their solution will work in future and are they taking product vision from all angles into discussion.
- Ask if their solution could be more generalized.
- Focus team on quality and encourage them to avoid one-off solutions.
I do not mean that you should try to guess future requirements and build features that won’t be needed. Purpose is to gain new viewpoints and to twist the problem.
How to decrease chaos in a team
When stagnation happens and chaos is reached, disorder should be decreased so that work can continue. Some ways for a team to decrease disorder are:
- Decrease democracy and select one person to come up with a solution that will work as a starting point.
- Take a small vertical slice and implement a proof of concept.
- Stop discussing and get to work. Once you have something to work with, start discussions again.
- Concentrate on one subsystem in order to reduce complexity on technology axis.
Communication at the edge of chaos
It may take a while for a team to really understand how others perceive a problem and to come up with a potential solution. Without some way to communicate progress team will easily slip into the chaos. I like to visualize things, so I draw. I mean draw like crazy. Class diagrams, domain models, architecture diagrams, story boards, you name it. The purpose of these visualizations is to help team to understand what it has accomplished, give it a shared canvas for discussing about solutions, and to communicate social representations. Biggest value for diagrams is just after drawing and they are not final project documentation as coded solution will most likely be somewhat different from the models.
Some concept models from our current work.
Productivity, creativity, and stress levels
If I have understood the very edge of chaos correctly, it is not very productive state in terms of end user value. Creative yes, productive no. When team is working to gain understanding of a complex issue, it inevitably uses more time to communication and change than when working on straightforward tasks. I feel that actual productivity increase is reached afterwards when we have understood the problem, made a consensus, and pulled out to less complex zone to do actual work. To enter “hyper productive” state, team will have to work like a pendulum, balancing around the edge of chaos. Working near chaos can be quite stressful for a team and it is important to watch how it copes with the stress. It is not a state where I would like to keep team too long at one time, because it will start to wear members down. However, amount of stress at the edge of chaos will likely depend on people’s thinking styles and others are more susceptible to it.
I will have to give more thoughts to this. If you know any good links or have real life experiences to share, I am very interested.
Updated myself with TOGAF certification
published November 24, 2010
It is a quite exiting moment when submitting a Prometric test… Today I passed TOGAF™ Foundation certification test after 3 days of hard studying and that makes me now an enterprise architecture guru, right? Well… not quite. But still, these days have been very good and I have learned lot about enterprise architecture and some best practices to implement it.
I am pretty much Agile and Lean proponent and you might be wondering how they will match up with TOGAF. Basically TOGAF introduces an Architecture Development Method, which is a core process defining how work is to be done. It is very much business focused and tries to find a way for a organization to align business with IT. I somewhat feel that it has same fundamental “problem” as ITIL , namely it manages process with document handovers and sometimes it feels that a document is the purpose for doing something. It surely says that bucks are collected at operations phase, but focus is pretty much with different documentation. OK, both frameworks have roots in big organizations and documentation bureaucracy is more justifiable in those.
TOGAF and ITIL both say that they can and should be customized to fit organizational needs. Then they go describing in detail how work should be done. A process that has to be tailored down is challenging for people as we will usually add some parts “just in case we need it”. This is also a problem with RUP implementations and they just tend to grow too big and non-agile. In this light, a method that describes a process with lots of “potential documentation” can almost accidentally be implemented as “heavy documentation”. It is like selecting movie candies from large selection, you will want to check every row and in the end you just have too much.
TOGAF does not give any guides for software development process and it is easy to implement actual TOGAF work package(s) using Scrum or XP. TOGAF even suggests implementing target architecture in “steps” (transition architectures) that fit nicely with Scrum release plan. However, many benefits of Scrum will be lost if we are just “sprinting though fully preplanned project”. Then again, I am not convinced that every project should be done using Scrum (check out Balancing agility and discipline) and in some cases PMBOK or Kanban approach will suite better. Key is to select correct process and forget about process fanaticism. But either way, people are doing the work, so in the end organization culture must be nurtured to produce top-notch results. Huh, sounds easy :)
All in all, I see very much value in combining TOGAF, Scrum, and ITIL while focusing on shortening lead time by eliminating waste from value chain using Lean tools. Next I will dig into Six Sigma, CMMI and COBIT to build a process behemoth that will solve all problems in the world. No, actually before that I will play few rounds of badminton.
Retro Scrum – coaching with metaphors
published October 24, 2010
“I am wearing multiple hats”, “hats off to the team”, “He was using black hat tactics”, metaphors – we all use them more than we realize. In addition, we have different ways of learning. My learning style is very much visual, so for me it is natural to draw things and learn by grasping big picture first before digging into details. Others learn by listening, but generally metaphors help people understanding new concepts and ideas.
According to wikipedia,
Metaphor is the concept of understanding one thing in terms of another
When coaching, pithy metaphor works like a charm. As people are naturally trying to understand new information by connecting it to previous knowledge, everyday related metaphor can be very effective. In addition, by presenting new information in multiple contexts you will make it easier for a learner to recall that data later. Below is an example of mapping Scrum into everyday cooking metaphor presented in retro theme (I also wanted to practice using Photoshop).
Scrum works like a big happy family (Scrum team) preparing to throw a dinner party (release new feature). Mom (product owner) has written down a menu (product backlog) and requests Dad and daughter (team) to prepare shopping list (sprint backlog), buy groceries and prepare platters (sprint). Family’s eldest son (Scrum master) will keep family’s small children (shields the team) out of kitchen (war room), makes sure that car works, and ensures that dad concentrates on preparing food rather than drinking beer. However, mom will want to check that correct menu is prepared, so she will check platters often (sprint review) and ensures that her party vision will happen. She will probably want to serve food shortly after it is ready, so that quests (users) won’t have to eat cold hamburgers (release often). Dad and daughter must keep kitchen clean (refactor) and try to avoid messy room (technical dept).
There :)
The image is available at Flickr and as A3 size with Attribution-NonCommercial-NoDerivs Creative Commons license.
Communicating product backlog
published October 8, 2010
Many customers that I have had conversation with, feel that one of their major concerns is a possible misunderstanding about product backlog items. Does a team really understand the meaning beneath user stories and is the correct solution built? Are there some good ways to enhance communication between a product owner and a scrum team?
Alistair Cockburn uses term “Richness of communication channel” to describe communication effectiveness between people (see a diagram here). What he claims, is that the least effective communication media is a written document. On the contrary, the most effective communication happens when two people are interacting face-to-face at whiteboard. From my experience, this is true.
Youtube contains nice presentations using motion graphics and scribing that communicate stories pretty smoothly. Walt Disney studios came up with storyboarding during 1930s which is something that is used e.g. in film industry. What I have tried, is to combine elements from all these into a product backlog storyboard in order to increase communication effectiveness.
Lets imagine that our team has to build a new feature to existing software. Product owner has written most of the features as user stories into product backlog. He has also produced some layouts how a UI should look like. These layouts won’t cover the whole solution and only work as a starting point. Problem now is that you have a product backlog which is very “cold” in terms of communication effectiveness and you will somehow have to increase richness when communicating features to the team. so, to be most effective we should meet at a whiteboard, right? Yes, but it is better to prepare stuff before whole team arrives.
What I have done, is drawn multiple storyboards like one below beforehand and used those as a “whiteboard”.
This is close to a user interface mock-up, but it tries to communicate the story without all detail in user interface. Storyboard gives us a shared visual representation and a story flow that can then be enhanced with people present. Storyboards should be hand drawn and are actually pretty fast to do. They can be hanged as a posters on a office wall, or discarded and redrawn in case they are incorrect. Storyboarding is quite effective method in cases where you yet have no real mock-up, and try to get people on same page.
Liferay – Deployment will start in a few seconds
published October 7, 2010
And then nothing happens. I Run into this situation today, where first deployment of portlet works just fine but then following ones do nothing. Tomcat catalina.out just says:
11:07:47,534 INFO [PortletAutoDeployListener:87] Portlets for [..war..] copied successfully. Deployment will start in a few seconds.
No files copied, no nothing. This is how I got it working (try step 5. first as it seems to solve problem):
1. Turn on Liferay debugging from admin console
Now log keeps saying:
11:58:09,542 DEBUG [BaseExplodedTomcatListener:138] [..war..] does not have a matching extension
2. Turn on Tomcat logging by setting “org.apache.catalina.level = ALL” to Tomcat /conf/logging.properties
There is loads of stuff, did not find anything interesting.
3. See what files are modified after deploy
-bash-3.2$ find . -mmin -2
./liferay/deploy
./liferay/tomcat-6.0.18/logs/catalina.out
./liferay/tomcat-6.0.18/logs/catalina.2010-10-07.log
Now that is weird. “Deployed” war just vanishes after copying.
4. Start removing stuff from war
Removed web.xml, liferay-portlet.xml, portlet.xml etc. from war file. Nothing helped.
5. Made a complete copy of a war and deployed that
Now this seems to work! After this I deployed old version. Also that worked now fine!?
Really weird, but that copy seemed to somehow solve the problem.
Environment:
Red Hat Enterprise Linux Server release 5.5 (Tikanga)
Java(TM) SE Runtime Environment (build 1.6.0_13-b03)
Liferay 5.2.2 CE
Tomcat 6.0.18
Is someone knows why it works this way, please comment…
Now with ITIL certification
published September 30, 2010
Last friday I passed ITIL foundations certification test which was something that I had been planning for a long time. ITIL is an acronym for Information Technology Infrastructure Library and basically it is a collection of books which contain best practices for developing and managing IT services. In this context “IT service” does not mean same as web application. ITIL provides practical knowledge for running your IT department so that it can serve internal and external customers efficiently. How does ITIL compare to software development in general and particularly to agile methods? I am glad you asked.
Frankly, ITIL does not have much to do with software development. It is very much water fall driven and works with document handovers. Developing a new service (which might contain several software systems) works roughly like so:
1) Start out with IT Service strategy and try to come up with a service that would be useful for customers.
2) Once you got a business case, start gathering business and functional requirements, write SLAs, OLAs and other contracts.
3) Gather all this information into Service Design Package (SDP).
4) Send this SDP “somewhere” where it is magically transformed into working software.
5) Deploy solution, do training and start normal daily operation control.
As you can see, process is very “water fallish” and step 4 is somewhat vague.
However, ITIL contains loads of good stuff like managing deployment processes, running IT services and dealing with changes for deployed services which are completely outside of agile scope. Of course it is not a silver buller, but many software projects would benefit from sound IT service management.
For agile enthousiast I will give to advices:
Digg into the ITIL as it will help you to better understand IT departments and contains usefull process-related information.
Service Design Package from ITIL Service Design lifecycle phase should be light and contain service vision, ROI calculations, business related documentation and top level features. Use those as input for an agile project.
Product packaging
published September 17, 2010
I have to admin that I have become an Apple fanboy. Usability and design of their products is just so good that it is quite hard not to like their gadgets. First impression is very important for us humans and we make snap decisions about product quality based on that impression. For Apple products, high quality starts from product packaging. All their packages look and feel something with a high quality.
There is much we should learn from Apple. First of all, I feel that too many software projects do not achieve top-notch usability and are producing mediocre user interfaces. Secondly, designs lack eye candy, which is something that Apple products definitely have. Many projects are in desperate need of an artistic web designer, who could take full responsibility of usability and high quality UI design. When this person does not exist, role is cast upon developers, which will in turn deliver mediocre results.
There seems to be a wide skill gap between a software developer and a web designer. Software developers are not very interested in usability and consider it somewhat secondary. Web designers have artistic creativity but have no interest in coding. As Scrum suggests, we should have a cross functional team but unfortunately in many projects team is just too homogenous and lacks artistic creativity. This creativity gap is then filled by buying layouts and mock-ups from web design companies.
This is like hiring two teams: a “visual team” and a “development team”. Of course, these two teams will not meet in person, and they only “communicate” with document handovers. Sounds crazy? Well, it is. These unnecessary handovers can distort product vision and hinder team from owning the visual plan. Much better option would be to hire a web designer and ask him to join team as a full-time member. I believe that this leads to better usability, finer architecture and less confusion about product vision.
The tale of the catching team
published September 10, 2010
Have you ever been in a situation where a software project is started with a clear roadmap and beginning works very well? Then after a while, “easy” parts of the software are done and suddenly new features are harder to implement because future plans are not clear enough.
It is almost like the story of the tortoise and the hare. The role of the hare is played by a product owner, the tortoise is played by a Scrum team. If product owner has other responsibilities or vision is not clear, we might end up in a situation where team “catches up”. Suddenly confusion increases because team is not sure what to do next and how to do it. The role of the hare can also be played by other system that team is trying integrate to. If both “client and server” are developed simultanously, client code can be ready before server which will hinder final testing.
An advise “Just make sure everything is ready enough when implementation starts” is very easy to give, but harder to implement in practise. You should, however, be aware of this if you want to avoid “the tale of the catching team” ;)
« Newer Posts — Older Posts »Subscribe to RSS feed
The Tag Cloud
Agile Business Coaching Coding horror Conference Customer Design of Experiments Future Group dynamics ITIL It should not be that hard Java EE Kanban Leadership Lean Liferay Methodologies Natural UI Performance tuning Process Productivity Quality Retrospective RIA Scrum Six Sigma Social psychology Software Software architecture Testing This is great TOGAF
WP Cumulus Flash tag cloud by Roy Tanck and Luke Morton requires Flash Player 9 or better.
Samuli's Links
The Blog Archive
February 2012 (1)
January 2012 (1)
November 2011 (1)
June 2011 (2)
May 2011 (1)
April 2011 (2)
March 2011 (2)
February 2011 (1)
January 2011 (1)
December 2010 (1)
November 2010 (1)
October 2010 (3)
September 2010 (3)
August 2010 (5)
July 2010 (2)
June 2010 (3)
May 2010 (4)
April 2010 (2)
March 2010 (6)
February 2010 (7)
January 2010 (3)
December 2009 (7)
November 2009 (6)
