2. Build Quality In
4. Defer Commitment
5. Deliver Fast
Many especially the management and sales department has NO idea about these three points (other than just we want it now or yesterday). Well yea, in this article, it came with priority listed as 2, 4 and then 5. But really in actual software house, how to achieve this whilst make the non I.T. staff in company understand. In my opinion, there is no immediate unless the software is ready. Development software is a iteration process and hence, that takes time. A software that without quality, that is without going through testing (manual or auto) is something that cannot be profitable. IMO, during scrum stand up meeting, there could be a lot of things discussed and to deliver on the spot is something extremely impractical. I think to defer such commitment to a later date and time will give positive result. That is, individual has the time to think, work and prepare rather than just bullshit just to answer that point 'deliver fast'. In order to achieve quality in software and to deliver fast, an automated tests is the only path to choose. Because of that, a quality end product can be achievable. If you are in software company, you should know this need time to accomplish.
6. Respect People
In a house, we have elder and youngster, in a company, we have different charts of ranking and in a country, we have different society in various lifestyle. But in a company, there are some companies really practice ranking habit and worst some promised flat organization but in actual day to day working style, show sign of ranking practice. IMO, in order to respect people, and to actually do it in line with what promised, ranking/position MUST be abolished. In order to respect people, there should not be ranking in principal or in practical. By respecting people and by removed ranking, only then a team can formed. If you have never feel what's a team like, please contact me.
Eliminating waste means eliminating useless meetings, tasks and documentation.
Countless this I have heard before during my past working life or from word of mouth from friends. I'm sure you have heard something like, "oh i have meeting from 9 to 11 and afternoon 2 to 4. Although I never discount the importance of a meeting, don't get me wrong, I have no ill wrong concept toward meeting, but a meeting should be concise and agenda oriented. A meeting should be a place where people discuss on a predefined topic and some questions which cannot solve over other communication channel.
It also means eliminating inefficient ways of working – like multitasking (!) – so we can deliver fast.
Seriously, to adapt computer multitask into human imho is just stupid. Rather than a staff that produced many things without quality, I choose a staff which is focused on the work and produced the work on time with quality. But really, look at Malaysia companies, how many really understand the actual multitasking definition and how they adapt the change necessary when things does not work in actual practical working life?
For example, many managers want to “optimize” individual developers by ensuring they’re always at 100% – but most of the time, this is actually counter-productive. Let’s not have people coding something that isn’t needed (or fully defined yet) just for the sake of coding, because that actually creates more work for us in the future
Generally I agree to this statement but should be a spare time, either this spare time can be used privately by the team to do something fun (games/hobby) or better yet, code something that can keep their mind sharp. There are many sites that provide this facilities such as hackerrank and StackOverflow when you can answer questions which really beneficial to the company and the individual itself. It's a win win situation really.
Along those lines, Lean says to respect that the people doing the work are the ones that best know how to do it. Give them what they need to be effective and then trust them to do it. Software development is about learning, so structure the work to ensure we’re continuously learning.
Countless times I see before how the manager and/or senior interrupt coder/programmer when they are actively solving problem. There are many problems come to this. First, when a programmer actively solving problem, an interrupt even 5 minutes will take away something programmer might forget later. Second, continuous interruptions means programmer cannot concentrate fully on their work and thus damage the company as a whole. It become worst if only programmer know how to code but not the manager or the management staff. There are numerous more to justify but enough to say that, to empower and to trust a staff to do what they are supposed to do, can produce many positive outcome. Even when a feature/bug fix screw up, it should be a journey of learning experience and the staff should inform accordingly and the manager/management should protect as a whole. This is one classic yet typical example you can hardly find. Remember, a trust is earn and build over time, it will collapse immediate if it is not fix.
3. Frequent delivery of softwarecontinuous delivery of software in actually means, coder added feature or fix a problem where the changes get commit into a software repository, sufficient coverage are done, build is okay and deliver to customer right after. But for a small company house, if any parts of the aforementioned did not do it properly, it only bring disaster. Trust me, I have seen this shit. It's better to understand self and adapt adequately than to pursue whatever out technology out there.
6. Face-to-face conversation is best
Not necessary, I have been in voice communication for years and I think voice communication work best. Why? because software progress normally require reference on work that they do. Text communication is even more vital than voice communication but they do serve complement to each other. Think of it, you don't need to look at your partner face to discuss things. However, you both require to look at the codes and discussed problem. We need to read the code at display and listen to understand problem at hand but not looking at each other. ;)
12. Regular reflection & adaptation
I agree regular reflection and changes are important. This also served a time when everyone can sit (or stand?) to listen and learn from each other. This is something seldom companies practice. This is another recipe to form toward a great team too. In essence, reflection and adaptation is something that should not be miss.
Last but not least, all these software development methodologies might work in company A or company B fully but that does not mean company like you should blindly follow. But if you are startup and have no clue, it is best to learn from this, to serve as a guide and improve and self reflect along the way. Most importantly, to form a team is more important than anything else.
