I recorded a webinar for CodeGenesys on a case study on Agile Testing involving my Australian Client called AgWorld.
Hopefully it conveys that quality is owned by everyone and quality starts well before a line of code is written.
This carries on right through the software development life cycle with the aid of automation tools to increase the delivery rate of completed software.
My latest blog is actually one written for my employer here in the United States, Code Genesys.
You can take a look at it here and is on the importance of shared purpose. Keep practicing that because it’s hard for first timers and anyone whose experienced for that matter. Well worth the investment in time🙂
I have an example of a company who go to great lengths to maintain their purpose. An old blog article written 2 years ago.
Thinking back to when I was learning programming in the 1980’s the instructors taught us about program creation by a visualization technique called Nassi-Schneidermann diagrams. Here’s a nice summary from breezetree.com.
I thought it was an excellent way to visualize program flow for a novice. It’s only needed for a short time and learners can quickly move to pseudo code. Most programmers can move beyond pseudo code as well.
Knowing the importance of visualization in the Kanban Method, I wonder if new students to programming are being taught via the Nassi-Schneidermann?
Can we use it to increase engagement with the people we are delivering software to? I suggest we can. I’ll leave you with this example from breezetree.com and ask can you understand the flow of the program?
This is a page from a great book by an important author in the software development field, Tim Gilb, called Principles Of Software Engineering Management. It came out in 1988.
The language is reminiscent of the time and the practices that were in place then, but it was ground breaking in that it talks a lot about what we call Agile Values today. In fact Tom Gilb invented his ‘Agile’ and ‘Iterative’ EVO methodology in the early 1970s. It’s mentioned in the book as well. This was well before Agile became what it is today – a business. Tom was so ahead of his time, I remember back then that Iterative development was never ever mentioned in schools and in the workplace.
And therefore, I think this Bill of Rights still holds relevancy. I made the challenge on twitter and some thought point 9 was not relevant, rather a relic of the past. I tend to think it’s misinterpreted in the twitter response. Here’s the link to the twitter feed and a snap shot below.
There is power in this for the worker here, even on performance. Leaders can use this to create an ethos of transparency. Looking back to look forward.
Not as many posts as the previous year with just 36. However the blog received more views that the previous year.
The Most Popular
Again, my review of L.David Marquet’s book Turn the Ship Around was the most popular. Seems like a popular book and the author regularly recommends looking it up. My series on Personal Kanban has trended well again but a long way back in the field. The blog on Realizing the Power of Agile Testing was initially popular.
2015’s favourites includes the case study on Agile Testing entitled Realizing the Power of Agile Testing. It was initially very popular through some sharing on Twitter and Linked In. Not a popular subject for web key word search it seems so it’s popularity was fleeting. The message is still powerful.
A blog added at the end of the year and received a number of hits (96 in two weeks – not bad considering overall hits to the blog) was a tip for those doing scrum to add workflow to their task boards. It’s called Avoid the Workflow Masquerade. I expect that to continue to be popular this year.
The Controversial Ones
This item on making the best of your abilities is controversial because it challenges some poor behaviours which are for the most part condoned but ultimately reduce the effectiveness of teams and the ability to hire new people.
The Unloved Ones
This one would also be termed controversial. It’s a rant about the bad behaviours at work. It has some tips at the end though. Didn’t get much love due to the nature of the article I suspect.
Looking forward to a new year of blogging in 2015.
Happy New Year – All the Best – Nick
I’m an Australian working in the USA coaching highly distributed teams. We speak English but even then there are slight differences, like Australian English and American English and even within America like from South to North.
We find it’s hard to get people to use video cameras. They are cheap however the culture tends to not encourage use of them. It’s always hard to collaborate at the best of times and distribution would be a good excuse not to do that.
Seems most distributed companies can’t get past just the phone and a little screen sharing. When we use just these, we can’t see each other’s facial expressions and body language. It’s hard to know how to react to feelings and we have to assume or turn up our intonation sense when listening (perhaps even speakers and listeners can make more us of their voice to relay feelings). Another big issue is having attention – where I work inattention is called ‘multi-tasking’ and we know that don’t work.
Overall, this is more a problem around the difficulties in collaborating and the fears around that. We’ll need to work on that to allow the tools to be useful. Make it safe. Create the culture and camaraderie of teamwork and reward that. Highlight even when people are doing things that harm teamwork via a team working agreement. Realization can quickly occur after that and a team can self correct.
Then there is technology, my friend Agile Bill Krebs – , is teaching and coaching on tools to assist the distributed work place. There are simple tools like join.me which is down the low end of the spectrum through to immersive environments like Minecraft.
The technology is there – it just needs a willingness to try using it and adapting to use it to it’s utmost advantage.
Your last resort is to abandon the distributed model. That can be avoided I suggest.
Here’s a comparison of David Marquet’s Ladder of Leadership which derives from his work as a nuclear submarine captain and writing his book Turn the Ship Around and then subsequent workshops and writings and the Kanban Method.
The Kanban Method says start where you are. Other frameworks require a more explicit transformation to new roles and ceremonies. The Kanban Method also says Improve Collaboratively and Evolve Experimentally (using models and the scientific method). Of it’s 9 values it also states Leadership. Acts of Leadership from every level.
A model that you can use to improve and create leadership from everyone is called the Ladder of Leadership (although not explicitly steeped in the scientific method, it is a model). It starts where you are. Everyone, and this doesn’t matter what position one holds, is looking to be told what to do. This is where mostly everyone is.
The Ladder of Leadership recognizes this. Everyone can use the model as a frame to help each move up the ladder to become more intentional. By recognizing where someone is on the ladder whilst in conversation, a colleague can frame a question using the next rung on the opposite side of the ladder.
Measurement of success comes via a proxy from other measurements like faster cycle times, better quality (less failure demand) and people should be happier and if they aren’t something is still awry.
It takes some time to achieve this. One must be prepared to stay the course despite the bumps in the road. If it doesn’t work on one occasion, reflect upon that. Realize we are humans, have a laugh and try again using what you’ve learnt. The ultimate aim is to create leaders not followers. Leaders can relieve bottlenecks and fix problems quicker and with more knowledge than someone further away from the problem.