As I am tending to do over the last few weeks, there is one part of the week 6 readings I want to place my focus.
Before we do that, as a second-year student, one of the clear advantages we have already encountered a lot of the seminal papers in the areas we are working. Last year I used to HATE when a second year said in class, "oh yea, we did that last year" and the lecturer would skip over it. So Im trying to avoid doing that. So many of the papers referenced in this week's readings have been covered in modules we have already completed, which makes it easier for us second years to grasp. We have already spent 6 weeks trying to get our heads wrapped around bloody structuration theory!!! So for that reason, I'm not going to talk about the classic Curtis, Krasner and Iscoe paper [one of my favourites from the course so far, for what it's worth]. My project shall indeed use it, as I do love their core point that we should not see requirements as things to be dragged from users heads. But that often requirements don't exist and have to be constructed from various human interactions.
In the Fiction of Methodological Development paper, Nandhakumar and Avison say,
Jim Morrison said it best, "people are strange.."! That is what is important to remember in all of this. You adapt process around all processes, but especially development to what team you have. One team will do Kanban, with many tiny tasks in an ever flowing board. With another team you have a small number of bigger tasks, reviewed monthly or something. It all comes back to the people! You want to look at the people on your team [& who your customers are, and who they have], and how you get the best from them. You adapt to your people and environment. I would not go full on Myers-Briggs with specific labels. But I cant argue with their general point, and how it drives who will work best with who [all things being equal].
In our Iona case study it seems to be clear [to me!] that as they became bigger and more successful, they lost some of that fun start-up culture. It was not fun anymore. But the other side of that start-up culture is that often bad processes often become embedded and at times you will get a hero mentality, of people and teams taking on huge burdens in an effort to be seen as "the best", and that also looks like it happened at Iona. That is where you need to step back at times and look at what you are doing, and why you are doing it. You need to examine who you have, if they are doing their best and if they are happy [and if not, how can you make things better for them and your customers. This is tied to the points above. Its about the social context of folks actions. At times its VERY important that a leader takes a step away. The leader needs to look at things being in place for the sole reason that person x did it this way once, and this becomes the process everyone else must follow. No knows why we do it, or why we expect that its slow or manual. But every time we do this slow manual process put into place by mister x it gets reinforced [in the Iona case, its the stupid long hours to support products!]
Before we do that, as a second-year student, one of the clear advantages we have already encountered a lot of the seminal papers in the areas we are working. Last year I used to HATE when a second year said in class, "oh yea, we did that last year" and the lecturer would skip over it. So Im trying to avoid doing that. So many of the papers referenced in this week's readings have been covered in modules we have already completed, which makes it easier for us second years to grasp. We have already spent 6 weeks trying to get our heads wrapped around bloody structuration theory!!! So for that reason, I'm not going to talk about the classic Curtis, Krasner and Iscoe paper [one of my favourites from the course so far, for what it's worth]. My project shall indeed use it, as I do love their core point that we should not see requirements as things to be dragged from users heads. But that often requirements don't exist and have to be constructed from various human interactions.
In the Fiction of Methodological Development paper, Nandhakumar and Avison say,
"There is one particular part of the "The development process therefore, far from being a life-cycle process, involves complex human actions and interactions. As Orlikowski and Robey (1991) claim, developers ``do not act in a vacuum'', but are influenced by various issues in the organizational context, such as their knowledge about methodologies and implicit social norms, the resources available to them and the organizational form and culture. Drawing on Giddens' (1984) structuration theory, we may see the development process in terms of cycles of interactions between developers' actions and social context in which the developers draw on their knowledge about organizational context and methodologies. Activities of the EIS team members, in turn, helped to reinforce this social context"I think this raises critical points which are easy to miss. We often obsess with methodologies and process or indeed with technology "we need to port this to the cloud, and all our problems will go away". As their study finds, is that it's all about people. A team of people who are people shy introverts will often be doing things very differently day to day than another team of extroverts shooting nerf guns at each other! These are extreme examples, but you find these kinds of teams in every large company. I once managed a team of developers in Kiev, and if micro-managed their work was excellent. But if left to their own devices, their work was sloppy and sub-standard. They needed to be told what to do at every level, and that was what they were used to. Contrast that with the team I worked with in Cape Town, South Africa. If I tried to micro-manage them I would have serious problems. They are much louder and stronger personalities. I gave them requirements and deadlines, and from then by and large got updates in morning stand-ups and at no other time.
Jim Morrison said it best, "people are strange.."! That is what is important to remember in all of this. You adapt process around all processes, but especially development to what team you have. One team will do Kanban, with many tiny tasks in an ever flowing board. With another team you have a small number of bigger tasks, reviewed monthly or something. It all comes back to the people! You want to look at the people on your team [& who your customers are, and who they have], and how you get the best from them. You adapt to your people and environment. I would not go full on Myers-Briggs with specific labels. But I cant argue with their general point, and how it drives who will work best with who [all things being equal].
In our Iona case study it seems to be clear [to me!] that as they became bigger and more successful, they lost some of that fun start-up culture. It was not fun anymore. But the other side of that start-up culture is that often bad processes often become embedded and at times you will get a hero mentality, of people and teams taking on huge burdens in an effort to be seen as "the best", and that also looks like it happened at Iona. That is where you need to step back at times and look at what you are doing, and why you are doing it. You need to examine who you have, if they are doing their best and if they are happy [and if not, how can you make things better for them and your customers. This is tied to the points above. Its about the social context of folks actions. At times its VERY important that a leader takes a step away. The leader needs to look at things being in place for the sole reason that person x did it this way once, and this becomes the process everyone else must follow. No knows why we do it, or why we expect that its slow or manual. But every time we do this slow manual process put into place by mister x it gets reinforced [in the Iona case, its the stupid long hours to support products!]
I love the contrasting teams story. Very difficult to have a single solution for sourcing. Now on the topic of leadership, perhaps if we'd had another person at the fore...
ReplyDelete