Blog
Talk to the global leaders in fleet management, vehicle tracking and personal safety
Since I’ve started at MiX Telematics I have become a self-confessed Apple fan boy. It all started with an iPhone and progressed to a MacBook. Nothing up to know has beaten the “unpacking” experience of each of these devices. The attention to user detail is really amazing. This post however, is not to convert people to Apple, but rather to show what can be done with some C# coding for the iPhone. Yes, it’s not a typo, C# code was used to write a basic iPhone application.
Objective-C, however much touted as user friendly by Apple, I have up to now found a cumbersome language to get into. Based on this and having followed the progress of Mono, the open source implementation of .NET languages such as C# and Visual Basic, I decided to invest some time in MonoTouch.
MonoTouch as described on the Mono website: “Create C# and .NET apps for iPhone and iPod Touch, while taking advantage of iPhone APIs, and reusing existing .NET code, libraries, and skills.” And I must admit, the last part of the above ”…reusing existing .NET code, libraries, and skill.” so far has proved to 100% on the mark.
I love agile games – they make learning fun and interesting. Also people tend to remember the lesson as they experienced it.
I did a kanban introduction game at work with our support team who are using Kanban and our Development team is using scrum. Most people dont know what Kanban is or why we are using it – so the aim of this session was to demystify the word kanban.
To start off with I briefly explained that Kanban meant “Visual Card”, and that it was a pull as opposed to push way of working, that it was responsive to change and based on Just In Time actions. I then went through the core concepts.
This originally appeared on Sam’s blog, Inevitable
So its one month later… what has happened?
After 1 week we started adapting the board. The first change we made was to add blocks numbered 1 to 10 in the todo column so that it was clear what was highest priority.
After 2 weeks some more board changes occured…
The second change was to move to a bigger board! We had all the issues that were being worked on pre-kanban on the board, but we excluded them from the limits on the columns. The result was a really messy board.
The third change was to introduce a “parking lot” column. Many issues were with customers or hardware, and they got “blocked” stickies but were holding up the process due to column limits.
The fourth change was to add a swimlane for “pre-kanban” issues. This way we could easily identify the issues with the current support team and those outside of the team.
All of these changes resulted in a much cleaner board, and made adhearing to (and noticing) the limits much easier. One glance at the board could now show bottlenecks easily.
After 3 weeks we held a retropective with a representative from each column attending. In order to get feedback from all people involved we also sent out an email asking everyone who was involved for feedback.
The questioned asked were:
General feedback – overall for the 3 weeks how did you feel about the new support process?
Select one:
Happy ………….. OK …………. Disappointed
Other comments:
What worked well:
What can be improved:
What doesn’t work:
Any suggestions:
Important to note is that everyone agreed that making issues and bottlenecks visible on a board works well – better than any previous attempts at managing support items. YAY!
Looking at the data collected we then used dot voting to highlight which problems were most important to the group and thus needed to be addressed first.
These were:
Clearing the backlog – Currently the backlog items are piling up as we are limiting how many issues the support developers can look at.
Knowledge Transfer – There are a handful of developers with loads of domain knowledge. As such they do more or less everything around those domains. We need to start the painful prcess of transferring this knowledge. Naturally as the domain expert is not doing the actual work it will be slower. The suggestion here was to try dedicated time from the experts – 2 hours a day for 3 weeks.
Support Process Flow – documented. Whilst the kanban idea was explained to the first group of developers going through it – it has not been explained to the second group, so they were a bit lost for the first day or so. Also the testers in the support team have never worked in an agile way so the stand up routine is still a bit odd to them. We agreed to do a basic diagram of how the board works and what each roles responsibility is. This way anyone can look at the diagram and quickly come to terms with the new process.
One additional small item was actioned:
Template for sticky – each sticky on the board looks slightly different – and it does get confusing. We will put up a template (start date top left, end date top right etc) for people to follow.
Our standup process has changed. We were going around the group – each person saying his bit but that meant jumping around all over the board and it was very confusing. After attending a Kanban course our Support Manager made the suggestion of starting from the last column and addressing all tasks there then working our way backwards to the first column. This is much better!
Moving from right to left emphasises the PULL of kanban, we are also able to discuss blockages in any of the columns as soon as we discuss the column rather than waiting till the end of the stand up. After some internet searching I came up with a new format for our stand-ups. This is now printed up on an A3 paper and stuck up next to the board as a reminder.
Another contentious issue is when to do full solutioning, when to apply a quick fix and when to add a change required to the product backlog for the development team to do. We have decided to have this discussion after our first column (Dev Analysis) and present the choices with pro’s and con’s for the Support Manager to decide on.
To add a bit of fun to the board I created South Park characters with some space to scribble your name underneath. We have 3 of each character. So each person on support can pick one that personifies them, add their name to the bottom (it wipes off) and stick that on the tasks they are working on.
We started with 3 developers rotating through support for the duration of a sprint. The idea is to balance this evenly between all 6 development teams and rotate amoungst them so that everyone gets a turn to be in support.
We’ve had some good days and some bad days. All in all, based on feedback and observations we are all getting more comfortable with the new kanban process, and starting to make it work for us.
This originally appeared on Sam’s blog, Inevitable
We are embarking on a journey… as with most journeys there is excitement, nervousness and a pinch of fear We are going to use Kanban for our support process. I’m going to blog about the journey – each leg promises to be exciting and full of lessons
“To get through the hardest journey we need take only one step at a time, but we must keep on stepping” – Chinese Proverb
The current suppport process is not working and we need something else. Kanban was explained briefly and those present are willing to give it a go. This is were I join the journey. I have been tasked with getting the process started – explaining kanban and assisting the support team to get going.
(I have previously blogged about Kanban and I have created a presentation explaining the basics. I also use Kanban for my personal items.)
First things first – we sat together and brain stormed over a whiteboard. “We” included me, the Customer Support Manager and the Senior Test Engineer. We had a basic understanding of the Kanban proposal, and an idea of the first “board”.
We then came up with any problem, issue, thought that we could think of and placed them on the white board. Some of these were easy to explain or deal with – so we chatted about them and moved them off the board.
We then moved onto the proposed board – looked at the limits, and looked at a definition of done for each column. Whilst doing this a bunch of new issue stickies were created – and went into the parking lot.
Each of us had some work to do and we decided to start the process in 4 days time. The developers will rotate through the support team, there will be 3 developers allocated at a time, for around 15 days (their sprint duration).
Day 1 – I created the board and had a meeting with all involved to explain what we are doing and how it will work. Our board is based on the kick-start example from Henrik Kniberg.
I gave a brief introduction on Kanban to the support team. We then played the Name Game to illustrate how limiting work in process works. No-one was opposed to the new process, but rather there were concerns about how it would affect individuals.
e.g: The 3 developers on the support team have no knowledge of Product X. Some valid points were raised:
We need to try the process and see what other concerns creep out. As with any process, frequent inspection and adaption will need to happen for this to be successful.
The Customer Support Manager will add stickies for his top 10 bugs. The Senior Test Engineer will document and train the necessary people in what needs to be done to meet the “Definition of Done” criteria. And in 3 days time we will have our first stand-up…
Sam wrote this on her blog, Inevitable
I’ll be the first to admit, up to mid last week, prior to the SA Scrum Gathering on the 2nd of September; Scrum was making no sense to me. Up to then, practicing Scrum was really frustrating. I’m not saying it is going to be smooth sailing from here on forward; I am sure we will still have several obstacles to overcome.
Different skill sets, legacy systems, inter-team dependencies, getting our heads around team self-management and how all of this should fit into the bigger picture of the company. And lastly, the big question, how to keep delivering value to business amidst all of this.
The single biggest revelation I had at the Scrum Gathering, was the following: Scrum is not efficient (at least not where we are at currently), however Scrum is effective.
So what does it mean? Well, our team has most definitely dropped the amount of tangible output we delivered in our 1st sprint compared to pre scrum days. By tangible output I mean “stuff” that we can show, i.e. “click-button-show-page-capture-data” “stuff”. This really got me down, where is the business value we are supposed to be delivering was the question I had more often than not driving home and some days, driving to work?
We have now established efficiency has dropped, what has happened to our time, what are we doing to be able to justify our pay check at the end of the month? We have become more effective in terms of what we knew all along we should have been delivering on previous development iterations. Unfortunately, this is the point where this post becomes fluffy, as we now are dealing with mostly intangible output.
We now have, for each piece of work, the following documentation:
Ok, so not a lot of it, but we have been able to create unit tests in our database code with proper sample data, and not just AAAAA and BBBB for data fields, but proper test data to satisfy our above scenarios, which in our environment is rather challenging.
A lot of effort wet into this, 1 because we are new to it, 2 because to test some stuff turns out to be pretty hard. This is to the nature of the environment and the project. We have however learned more of each of these aspects. Did I mention we are a brand spanking new team with sparse domain knowledge?
Not in the sense that we shared a keyboard or mouse or even half a screen or desk, however we did sit together to figure out the problem and create a solution everyone in the team is able support should it be required for each piece of work we committed to.
What makes the other guy tick, what she/he is good at, what does he/she sucks at and in which areas would she/he like to gain more knowledge? Help me help you so that we can be the best team we can be.
So let us look at the value proposition again. Yes, we are not currently delivering the same amount of tangibles, but we are forming a team with the common goal of delivering value to business. We are sharing our knowledge, improving our skills and putting down a knowledge base of all work we are doing. Therfore enabling people joining and/or taking over form us, making life easier for them.
So am I converted to scrum? Time will tell. The honest truth is I can see value, but I can also see this is going to be hard. We are definitely finding ourselves about to progress through the typical stages of Tuckman’s stages of group development – Forming, Storming, Norming and Performing (Adjourning and Transforming).
We will have to take it sprint by sprint.
Chris originally posted “Getting comfortable with SCRUM” on webEffects
Ok. So now im a certified Product Owner.
The course was interesting and it’s always good to hear about other people’s pain adopting scrum and where possible giving concrete help.
It was awesome to spend the two days with people from MiX and watch them growing into their new position.
MiX Telematics attended the Certified Scrum Product Owner (CSPO) training course at the BMW Pavilion in Cape Town led by Peter Hundermark from Scrum Sense.
It was an engaging two days with MiX being represented by Francois de Wet, Zoe Zenkins, Evangelos Gikas, Charles Tasker, Catherine Lewis, Tony Franco, and Izak Nel. During the course attendees became familiar with the role of a Product Owner and the best practises within Scrum.
The steps of test first design (TFD) are overviewed in the UML activity diagram of Figure 1.
Once the tests pass the next step is to start over. You may first need to refactor any duplication out of your design as needed, turning TFD into TDD.
All credit for the post to Scott W. Ambler
