I’ve been building a little home project for the past couple of months, just to experiment with programming languages and frameworks. During this time I managed to put together a simple continuous delivery pipeline, completely automated and free of charge. In the following paragraphs I’ll describe how I, in my next home project should connect those pieces of puzzles together. Maybe it will be useful for others as well. Continue reading “Notes to myself: free CD pipeline for home projects”
For several months I’ve been trying to convince management to introduce some innovations in order our product to be more stable, better performing and of higher quality. Among those ideas the two most important are already introduced and well functioning at several software companies of huge size. Namely, those are Kaizen and FedEx days (more on those a little bit later).
I don’t think I wasn’t persistent enough. I was trying on several levels. I went to innovation days, used idea boxes, had face to face conversations and so on. The result was always the same. The answer –in each and every case- was, “Wow, these are great ideas, we can really profit from these things. We’re definitely going to try these things out. Thanks for pointing it out”. Unfortunately, for some reasons the implementation of the ideas never took place. Too bad, there’s a lot of nice things about them.
Kaizen is a technique of continuous improvement. In its simplest form, it only needs a whiteboard, some kaizen cards with improvement ideas and some creativity from the team’s side. An idea can be process or technology related. The point in this way of collecting ideas is the infamous (mainly retrospective-related) phrase of “Gosh, I had a great idea, but I can’t recall it”. The idea behind kaizen is something like: any idea is worth discussing, none is worth forgetting. You get an idea, just write it down and put it on the board, so everyone can see it/think about it.
FedEx days are special working days, when no one is allowed to do their normal, every-day work. Instead, everyone is required to work on a kind of own project, with the only restriction that it has to make either the process or the product better. See how things connect? Those ideas collected on the Kaizen board can be developed/introduced during FedEx days. In order to get the best results, these occasions have to be organized regularly (bi-weekly or monthly).
My current team is a newly set-up one. Some people are having hard times understanding the basics of different agile methodologies. At the beginning there were no clear rules, we had a hectic whiteboard and several severe arguments. There was no way of introducing any improvement. The first thing was to do Kanban, with all its principles, practices, board-design stuff and so on. This took some time (and it still goes on. Some people just don’t want to get why Kanban rules are better than chaos. Even if they see data-based results. More on that in an upcoming post).
As Kanban was more or less in place and management was still ignoring the concept of kaizen, I decided to introduce it on team level. The idea was simple: I “designed” a kaizen note template, simple as hell: a table with two rows: idea and benefits:
One day I added a new Improvements section to the Kanban board and made the empty kaizen notes available. And guess what; it turns out that people actually HAVE improvement ideas. And they are keen to share them. This is how the board looked like before the first session of discussing the improvements:
Ideas are discussed; after reading the kaizen note’s text, the author is given the opportunity to clarify any unclear aspects about the idea. After a short debate where everyone can tell their thoughts, a simple majority voting is held. If an idea is passed, it becomes a new team principle. Rejected ideas become buried forever.
Ideas can be real simple and straightforward things. Things like “I think we should implement different classes of services. Benefits: better and faster work”. Improvements should not be thought of as world-saving things. Simple tiny steps can lead to better achievements.
A current state of the whiteboard:
As per now, I can say Kaizen works just fain on team level. Maybe as the project advances (as we’re working on a new,greenfieldproject) we can introduce FedEx days on team level as well. So we could tell managers “see, that’s why we should have it on organizational level”.
In case of agile development, we usually don’t run into hundreds of lines of documentation, with detailed diagrams, architecture proposals etc. This is good for several reasons; developers can use their creativity in order to materialize requirements. This way, people won’t fall into the pitfall of blindly following someone’s vision either.
However, UML may become in handy at feature development. With just a small investment (as low as the price of a whiteboard) a team can boost their productivity. This is how: promote a whitheboard as “design board”. The design board has no other role, than to store the current architecture of the feature under development. It, of course, supposes that each and every team member updates the board whenever they make a change to the current state.
One might argue that there are a lot of software tools out there, why not use those? Well, the answer is simple; people are lazy (and forgetful, in the same time). Even if the UML diagram is stored somewhere everyone has access to, they won’t open it, let alone update it. They simply forget it, becouse the thing is not in front of their eyes all day long. However, if it is present materially, people actually tend to update it on a regular basis (also, daily standup meeting is a really good period to remaind everyone to do so, in the case they somehow forget it). The diagram doesn’t have to be that detailed. It’s perfectly enough if it contains the classes and interfaces, associations (uses, implements, extends …) and main methods.
How does this help increase velocity? Simple. People don’t have to randomly open different classes in order to find the right one to place some new code in. They just take a look at the board and know immediately how classes are related, which is the right one for the new logic. They also don’t have to remember all the class names and the relationships between the different components. Planning meetings (along with task breakdowns) will also get shorter. It eliminates the phrases that start with the infamous “well, I guess…” stuff; people will talk about facts not beliefs. Less stress, less time spent on arguing.
You probably know, or at least heard of Planning Poker. It’s a very funny event; the whole team gets together with the product owner, who presents the upcoming user stories one by one. After each story presented, the team have to estimate the amount of work that should be done in order to complete that user story. Continue reading “Planning poker et al”
I’ve already complained enough about us not being agile enough. I also realized that complaining and crying will not help us solve the situation we got into. There were a few problems arisen, ranging from tiny to not-so-tiny. Of course most of them will not go away overnight. It’s useless to tell “we’re doing completely wrong” and not to do anything about it. As one of my former colleagues would always say, “the s**t has to go away”. However, it only goes away if we found out which the s**ty parts were. Continue reading “Hey Ho, Let’s Go (Agile again)”
Today I’ve seen a set of interview questions. What actually caught my eyes was the following question/task:
Write a yesterday function, based on the Calendar API.
At the company I work for, we have several project roles, namely :
- System engineers
- Software engineers
- Function test engineers
A story that happened to my team in the past has made clear that traditional ways of working need a bit of revision.
One day, adding a new feature was decided by our product management. It was quite a big feature, with a lot of coding, innovative solutions, automating parts of an existing system. In our company, the life-cycle of a feature starts at an implementation proposal-writing phase. These proposals are actually sets of requirements, coming from our “customers” (we don’t have customers in the traditional meaning of the word, but anyway, it doesn’t really matter. Although I know that documenting requirements is not part of the agile framework, this document is really needed due to the lack of “real” customers). Our system engineer has come up with a proposal, that at some point, stated – the system shall somehow distinguish between different categories of objects.
The document was then handed over to design people. They started to find out how those objects should be distinguished. After several brainstormings, design discussions and debates it was decided that a best solution would be a new GUI element, namely an extended capability-table. However, swapping the old table with the new one took a lot f time. New methods were needed to be introduced to make the table compatible with the old implementation. This automatically generated a two weeks lead time, which also made the management a bit upset.
Finally, the implementation was ready, the increment was passed on to be function tested. Guess what happened; the new table was incompatible with our automated test cases, resulting in a (!)one month lead time. A whole team needed to be allocated to fix the broken test cases. Managers started crying, release date was postponed several times.
So we drew the conclusion that both design and function test should be somehow involved in requirements gathering. In a meeting of just one hour, we decided that:
- From time to time a little internal document review (thanks for the term, István) will be held; Designers can ask questions here, share opinions, give voice to doubts etc. Such a way everything written down in the document can be reconsidered before anything is made final. These meetings can generate prototyping and analysis tasks, in order to clear technical doubts.
- Component prototypes will be created by a couple or more designers. In order this to be successful system people will attend standup meetings. Short discussions will be held; system can answer “daily questions”
- There will be created a prioritized backlog for prototypes. The backlog will be administered by product owners (=system people), and will be reorganized in every two weeks.
- Function testers will also be involved in document elaboration. They will create automated test cases and stress tests for the above mentioned prototypes.
- Design people will be given the opportunity to take part in splitting work items into user stories.
The next implementation proposal will be written based on the action points above. We expect that more tricky details will be uncovered, making design and testing more fluent. We’ll see…