Even though annoying, the small problems sometimes help you find the bigger issues. The last week has been a plethora of small breadcrumb sized mishaps, now the loaf has been found and the satisfaction can’t be denied.
Visar inlägg med etikett software. Visa alla inlägg
Visar inlägg med etikett software. Visa alla inlägg
måndag 6 december 2010
tisdag 29 juni 2010
fredag 29 januari 2010
Random (s)crums
Some random “things” that I will take away from the CSM-course:
If you need a lot of system design you should still parallelize design and implementation (i.e. do it within the sprint) but it would be wise to add a Sprint Zero focusing on system design alone. This sprint will most probably be a little bit longer than normal sprints (depending on your system).
I will probably take a look at the book Software by numbers.
Ok I’ll cave; using modeling-terminology Scrum can be seen, roughly, as an instance of “Lean”. At least most of the basic principles, or values, are the same.
The Spec/Developer game that we played at the training should be played in every organization… the quick lessons learnt from that one are so easily neglected on an everyday basis.
When e.g. building cars or similar products there are a very strong focus on time, technology and cost, why is value repeatedly left out of that equation? Ok this one is not from the training itself but in Scrum the focus is on value and if anything you should, when prioritizing, look for at least MMF, Minimum Marketable Feature.
I should revisit the agile architecture work together with Peter and Peter. We are on the right track there and architecture is one of the difficult questions when talking Scrum. The answer at this course was that “architecture and infrastructure are highly prioritized non-functional requirements”.
Scrum in large organizations is difficult. Scrum in large organizations developing embedded products is even more difficult. But then again it is difficult using waterfall as well.
If you need a lot of system design you should still parallelize design and implementation (i.e. do it within the sprint) but it would be wise to add a Sprint Zero focusing on system design alone. This sprint will most probably be a little bit longer than normal sprints (depending on your system).
I will probably take a look at the book Software by numbers.
Ok I’ll cave; using modeling-terminology Scrum can be seen, roughly, as an instance of “Lean”. At least most of the basic principles, or values, are the same.
The Spec/Developer game that we played at the training should be played in every organization… the quick lessons learnt from that one are so easily neglected on an everyday basis.
When e.g. building cars or similar products there are a very strong focus on time, technology and cost, why is value repeatedly left out of that equation? Ok this one is not from the training itself but in Scrum the focus is on value and if anything you should, when prioritizing, look for at least MMF, Minimum Marketable Feature.
I should revisit the agile architecture work together with Peter and Peter. We are on the right track there and architecture is one of the difficult questions when talking Scrum. The answer at this course was that “architecture and infrastructure are highly prioritized non-functional requirements”.
Scrum in large organizations is difficult. Scrum in large organizations developing embedded products is even more difficult. But then again it is difficult using waterfall as well.
måndag 21 december 2009
SEMAT
According to this article Ivar J is tired of the moving target… that development teams are so quick to embrace new methods in search for the silver bullet. But as Ivar correctly point out there’s no silver bullet available. So now “he” (as co-founder of the SEMAT community) will create a new method for the development teams to embrace, a “standardized” process, a silver bullet.
If he succeed it will definitely be an accomplishment, but until then we will have to live with the irony.
Ok I guess I’m a bit harsh, and after reading through the comments of the article (where Mr Jacobsson comment himself) the article might be a bit over the top… but then after reading through the SEMAT webpage it still doesn’t taste like cake. It seems as a nice and pleasant idea alright but I can’t find any trace of real substance. And when reading through the limitations of the so called Kernel I can’t stop to wonder what’s left to include…
Hm and now after a couple of minutes writing about it I’m not sure if I agree to all the statements leading up to the “need” for SEMAT.
Is software engineering really “gravely hampered”? And if so is the problem really the “huge number of methods and method variants”? What do you think? For me I haven’t decided yet, if this would be a topic for a debate match I think I just as easily could play for the home as for the away team…
…when something is grey you can always make dramatic effects by turning it into something black and white.
I guess it’s not so much about incorrect methods/processes as it is how they are applied and who’s doing the work. Context and people. At least to me.
If he succeed it will definitely be an accomplishment, but until then we will have to live with the irony.
Ok I guess I’m a bit harsh, and after reading through the comments of the article (where Mr Jacobsson comment himself) the article might be a bit over the top… but then after reading through the SEMAT webpage it still doesn’t taste like cake. It seems as a nice and pleasant idea alright but I can’t find any trace of real substance. And when reading through the limitations of the so called Kernel I can’t stop to wonder what’s left to include…
Hm and now after a couple of minutes writing about it I’m not sure if I agree to all the statements leading up to the “need” for SEMAT.
Is software engineering really “gravely hampered”? And if so is the problem really the “huge number of methods and method variants”? What do you think? For me I haven’t decided yet, if this would be a topic for a debate match I think I just as easily could play for the home as for the away team…
…when something is grey you can always make dramatic effects by turning it into something black and white.
I guess it’s not so much about incorrect methods/processes as it is how they are applied and who’s doing the work. Context and people. At least to me.
måndag 5 oktober 2009
Youtube it
Preparing for a conference today so not a lot of blogging but here's two links.
6 minutes on agile testing, maybe not 6 awesome minutes but there are some interesting quotes worth thinking about:
Agile testing
If you got a bit more than 6 minutes check out this Google techtalk with Mary Poppendick:
Leadership in software development
6 minutes on agile testing, maybe not 6 awesome minutes but there are some interesting quotes worth thinking about:
Agile testing
If you got a bit more than 6 minutes check out this Google techtalk with Mary Poppendick:
Leadership in software development
torsdag 1 oktober 2009
Travel as I wait
Gunilla Hammarberg, not only my boss but also a rock-solid engineer, said something I'll steal: "Architecture is an activity rather than an artifact". Why is this so obvious but still not?
For me it is clear that this is the correct mental picture but still it is not obvious that this is how it works.
When we use processes that says something like "by gate X you should deliver document Y" people tend to focus on getting that document done, or? Especially since in many companies we build up a very large organization to check that document Y actually was delivered by gate X. If the people chasing the document is stronger than the persons behind them it don't take long until the authors are bullied into a document factory. When it comes to architecture I think it takes strong personalities to see through this and to get acceptance in their respective organization to shift focus.
Don't get me wrong, I don't say stop writing that System Architecture Description but shift focus. Spend 20% on the artifact and 80% on activity instead of the other way around.
When looking at it from the Lean angle architecture as an activity becomes even more clear. The quite common artifact-driven organization is a easy example of a "push" system and even though a lot of SAD:s are good documents it doesn't take long to identify a lot of Mura, Muri & Muda - or waste.
@"Travel as I wait": Since I know that a Philosophy-student (click and listen, he's not only philosophical but also an excellent musician) is reading this I might as well educate him a bit:
Lean Software Development in brief(s)
For me it is clear that this is the correct mental picture but still it is not obvious that this is how it works.
When we use processes that says something like "by gate X you should deliver document Y" people tend to focus on getting that document done, or? Especially since in many companies we build up a very large organization to check that document Y actually was delivered by gate X. If the people chasing the document is stronger than the persons behind them it don't take long until the authors are bullied into a document factory. When it comes to architecture I think it takes strong personalities to see through this and to get acceptance in their respective organization to shift focus.
Don't get me wrong, I don't say stop writing that System Architecture Description but shift focus. Spend 20% on the artifact and 80% on activity instead of the other way around.
When looking at it from the Lean angle architecture as an activity becomes even more clear. The quite common artifact-driven organization is a easy example of a "push" system and even though a lot of SAD:s are good documents it doesn't take long to identify a lot of Mura, Muri & Muda - or waste.
@"Travel as I wait": Since I know that a Philosophy-student (click and listen, he's not only philosophical but also an excellent musician) is reading this I might as well educate him a bit:
Lean Software Development in brief(s)
Architecture for the jilted generation
Riding my bike to work this morning through the pouring rain was excellent. The noise in my head from the Chinese water-torture going on with the rain dripping against my hoodie made me almost as creative as trying to sleep a late night.
The subject that keept me thinking so hard I almost don't remember the actual bike ride was architecture (ok I admit, this probably says a lot about me on a not-so-subconcious level).
How do one become an architect? What are the traits that we associate with the role? If we should post a job opening for architect what would be write? Some might say it is easy but is it really? For a discipline that we still seem to argue a bit about (how to deploy it and what it means) it surely can't be easy to recruit people to do it?
I think there are some interesting questions associated with the architecture role. For a SW-company would you even consider an architect without programming experience? I would guess not, or? What about an embedded-SW company delivering tangible consumer products such as cell phones, rockets or cars? I lean (no pun intened) towards a no but this is not so black&white in reality. What about other non-technical skills? Ever considered requiring pedagogy skills or offer that as training to an architect? Or should that be an innate skill? How about rethorical skills?
If you would hire a rookie straight from the Uni and show him the path towards becoming an architect what would that look like? In real life the system engineer often become the architect but does great system knowledge automatically mean that you are a strategist able to see the bigger picture?
Hm a lot of questions and not so many personal opinions. I'll take a stab at it:
* I think that architect shouldn't automatically imply promotion. It is a role with equal value to the system engineer, the coder, the tester.
* I think architect implies a certain personality, the person that can stand infront of an intersection and convince everyone to turn left.
* I think that an architect, whether it is a system architect or a software architect, should be able to "think programming" (some got it some don't, it is like e.g. philosophy... you can read a lot and learn philosophy but that doesn't mean you think philosophy... and I believe you can think philosophy without reading a lot).
* I think a system architect must have a commercial side being able to connect with product management and the market.
* I think an architect must have a skill-set that ables him/her to vizualise ideas.
So to shape the rookie I might suggest something like this straight of the bat:
- Work a bit where it happens, with the systems engineers and coders.
- Work a bit with testing. Everyone in our business should work with testing at some point.
- Learn e.g. UML
- If the existing architecture is e.g. modular with different concepts try to understand those
- Work a bit with project management
- Try to work a bit with the product management
The subject that keept me thinking so hard I almost don't remember the actual bike ride was architecture (ok I admit, this probably says a lot about me on a not-so-subconcious level).
How do one become an architect? What are the traits that we associate with the role? If we should post a job opening for architect what would be write? Some might say it is easy but is it really? For a discipline that we still seem to argue a bit about (how to deploy it and what it means) it surely can't be easy to recruit people to do it?
I think there are some interesting questions associated with the architecture role. For a SW-company would you even consider an architect without programming experience? I would guess not, or? What about an embedded-SW company delivering tangible consumer products such as cell phones, rockets or cars? I lean (no pun intened) towards a no but this is not so black&white in reality. What about other non-technical skills? Ever considered requiring pedagogy skills or offer that as training to an architect? Or should that be an innate skill? How about rethorical skills?
If you would hire a rookie straight from the Uni and show him the path towards becoming an architect what would that look like? In real life the system engineer often become the architect but does great system knowledge automatically mean that you are a strategist able to see the bigger picture?
Hm a lot of questions and not so many personal opinions. I'll take a stab at it:
* I think that architect shouldn't automatically imply promotion. It is a role with equal value to the system engineer, the coder, the tester.
* I think architect implies a certain personality, the person that can stand infront of an intersection and convince everyone to turn left.
* I think that an architect, whether it is a system architect or a software architect, should be able to "think programming" (some got it some don't, it is like e.g. philosophy... you can read a lot and learn philosophy but that doesn't mean you think philosophy... and I believe you can think philosophy without reading a lot).
* I think a system architect must have a commercial side being able to connect with product management and the market.
* I think an architect must have a skill-set that ables him/her to vizualise ideas.
So to shape the rookie I might suggest something like this straight of the bat:
- Work a bit where it happens, with the systems engineers and coders.
- Work a bit with testing. Everyone in our business should work with testing at some point.
- Learn e.g. UML
- If the existing architecture is e.g. modular with different concepts try to understand those
- Work a bit with project management
- Try to work a bit with the product management
Give this 5-10 years.
måndag 28 september 2009
An interesting quote
I don't know how I ended up there yesterday, on some random guy's Twitter page... so I can't provide a link to it...
But anyhow he, the random guy, wrote this:
"SCRUM brings coordination of action, which is critical. Software architecture brings coordination of intent and insights."
Maybe not the most shocking or difficult line to come up with but hey he wrote it and I didn't... I kind of wished I did though 'cause I like it.
So if you look at it from that perspective how do you coordinate intent and insight? Maybe we should embrace that there is more to it than producing documents, excel sheets and UML-models? That there is a lot more to "architecture" than the technical aspects that we somehow like to indulge a little bit too much in?
The first thing I would start with I would steal/borrow/use from Scrum and the agile "world" where one common theme is the importance of Product Management. Step one for "Architecture" would be to reconnect (or strenghten the relationship) with Product Management in order to increase the insight in both ends.
Step 1 from a bigger perspective would probably be to look at Product Management directly so that "architecture" (and everything else) has something functional to reconnect to...
But anyhow he, the random guy, wrote this:
"SCRUM brings coordination of action, which is critical. Software architecture brings coordination of intent and insights."
Maybe not the most shocking or difficult line to come up with but hey he wrote it and I didn't... I kind of wished I did though 'cause I like it.
So if you look at it from that perspective how do you coordinate intent and insight? Maybe we should embrace that there is more to it than producing documents, excel sheets and UML-models? That there is a lot more to "architecture" than the technical aspects that we somehow like to indulge a little bit too much in?
The first thing I would start with I would steal/borrow/use from Scrum and the agile "world" where one common theme is the importance of Product Management. Step one for "Architecture" would be to reconnect (or strenghten the relationship) with Product Management in order to increase the insight in both ends.
Step 1 from a bigger perspective would probably be to look at Product Management directly so that "architecture" (and everything else) has something functional to reconnect to...
Prenumerera på:
Inlägg (Atom)