I have been managing, I have been managed, I have been commanding and been commanded, I can honestly tell you that none of the management techniques is optimal.
In the last 10 years the Agile Kanban way of management has been very popularized across startups and enterprises in various sizes and disciplines, yet while I have been using the agile technique very successfully I often see firms and companies doing it wrong and it’s worse than not doing agile management at all.
But the real problem arises when you are having this agile regime, you see the manifesto of agile development did not talked about tasks in stories and it did not talked about point and dailies nor it talked about breaking each task to very small predictable task you know how long it will take [by the way if it was truly working this break down would been done by project managers using ms project or visio predicting exactly how long it takes to build a software project, you just can't, except it or move to another industry].
The agile manifesto talks about prioritization mechanism, it says, “Individuals and interactions over process and tools” that's all folks, it does not means that there is no management process it just gives you the idea what to prefer, YET for most of the companies the operated agile do focus on the process and tools, the daily and the board and the points and the velocity, sorry guys this is not agile development this is fragile development! Just let your engineer's interact freely and provide individually enhanced software delivery.
Working software over comprehensive documentarians, nobody it doing this right, let's take the following REST API to create calendar schedule, as an example:
There is almost nothing right with this example, since you really need a whole book of documentation to understand this API call, what the hell is sequence_id, app_id, app_secrete, etc....?
It is bad, not because it does not follow the right API coding, yes it is rest, it has some security keys in the header, it uses POST for 'create' and so on, it is bad because you need to write documentation for it, and all your customers should read this Mambo-Jambo piece of horrible REST API documentation, this is not agile way it is fragile way.
For example I could implement the same API in the following way:
post https://api.myclendar.com/v1
header:
token: only_one_api_token
body:{
required: {
when: "2020/jul/01 20:20:15",
duration: "15 minutes",
alerts: ['1hour @email', '15 minutes @sms']
you got it....
},
optional: {
other_participants: ['someone@example.com', 'other@external.com',...]
}
}
I do not consider myself as the best API designer ever, I did make a few mistakes but I just showed you a way to make things work instead of writing documentation, that's it, you really don't need to document and your customers don't need to read it, no task to write documentation, no story no Kanban board, agile way!
I think that "customer collaboration over contracting" is the lean startup way, and it just works as more startups embracing this approach, yet it is crucial to follow those lines, invision is excellent tool, use it, and don't hold to it as a contract, do before, correct later, don't wait, that's it! no more.
"Responding to changes over following a plan" is a key point, it is the master key for all doors the key maker in the matrix if you'd like, yet is often not really understood as 'agile' and leads the team to be fragile, most of the managers interpret this part to be the whole agile issue and think that it is the teams willingness/capacity to change according to market needs, and it is wrong, the Responding to change means the following: If you have a problem to solve, or in developers language when you write your code or solution and you come across a dilemma to choose between couple of way to implement (consider 15%-20% difference in implementation time to be neglected) you should select the way that will be more flexible to future changes as you see it today, that is it! So reaching up to the point that I am going to give you more advices, prefer team large chunk of task, let the team operated the way it choose, and let the solution design and implementation be flexible to future changes in the cost of time to finish the task or the risk you take.
for example suppose your company like to add an ai based computer vision component, let's say you are willing to put 4 workers on this task and you have allocated them from other departments for 8 weeks, to provide the best solution, no spec just expectations:
The component should recognize vehicles in front of the camera and mark the items.
We prefer to have the ability to distinguish between tracks and other types of vehicles
The time the algorithm has for recognition is 300 milliseconds
Your data is ready on Kaggle/S3 and you have $10K for cloud computation
GO!!
so the team starts, not breaking the story into predictable sub task, it won't help, start by identifying a four milestones that the team would like to achieve, say in the first two weeks they expect to have initial naive TensorFlow running on the cloud, on week four they would like to test, two very very new approaches they heard on, on week six they would like to refine the results and at the last two weeks they plan to improve convolution and fine tune pipeline.
That's it if you are managing this team, and you are working with them and you have the right personnel you'll have the best solution you'll be able to get.
It does not mean that there is no daily update, there should be, for the one who stayed late and the ones who came early, for general information sharing you have not made it through the day, but not for tickets stitching, tasks moving between columns, none of that! you can do Kanban board for your own needs.
I would like at the end to add one role to the manifesto:
Prefer automated task over doing things over and over again:
It means that you need to setup CI/CD pipelines first then write your first line of code or TDD, and prefer resilient code over testing!
Comments