Comments for Carl Bruiners http://carlbruiners.com Agile / IT Development Consultant Wed, 16 May 2012 21:37:39 +0000 hourly 1 http://wordpress.org/?v=3.3.1 Comment on ITIL, SLA’s and Agile by Cleiton http://carlbruiners.com/2011/12/itil-slas-and-agile/#comment-356 Cleiton Wed, 16 May 2012 21:37:39 +0000 http://carlbruiners.com/?p=424#comment-356 Hi Karl,Thanks for the blog nice and concise expsesrion of agility.Regarding Scrum, some Scrum teams also have multiple Outcomes. Or maybe I should say, there's one Outcome and a number of intermediate steps towards that Outcome that are smaller Outcomes in their own right.Those intermediate steps would be individual backlog items/user stories/features that may or may not be delivered at the same point in time. That is, while a Scrum team might have a sprint goal (Outcome) of Charge Our Subscribers they might deploy the ability to charge credit cards into production four days into the sprint, electronic invoicing a couple of days later, etc.What I describe here isn't canonical Scrum, perhaps, but it's not exactly against the dogma either. Hi Karl,Thanks for the blog nice and concise expsesrion of agility.Regarding Scrum, some Scrum teams also have multiple Outcomes. Or maybe I should say, there’s one Outcome and a number of intermediate steps towards that Outcome that are smaller Outcomes in their own right.Those intermediate steps would be individual backlog items/user stories/features that may or may not be delivered at the same point in time. That is, while a Scrum team might have a sprint goal (Outcome) of Charge Our Subscribers they might deploy the ability to charge credit cards into production four days into the sprint, electronic invoicing a couple of days later, etc.What I describe here isn’t canonical Scrum, perhaps, but it’s not exactly against the dogma either.

]]> Comment on SCRUM in name, not in nature by carl9167 http://carlbruiners.com/2010/10/scrum-in-name-not-in-nature/#comment-354 carl9167 Wed, 16 May 2012 20:18:33 +0000 http://192.168.0.2/wordpress/?p=122#comment-354 Hi Muse, Though not inline with the original blog, thanks for sharing this, particularly as you have touched on many issues. You've made some interesting and valid points, you clearly have mastery in the development department, statical code analysis, BDD, etc.. is all very much at more advanced end of development. My take is that it isn't only the architect that needs to be empowered, it is important to empower the whole team; BA's, QA, Developers / engineers, designers, UX, UI, etc... Architects should be fountains of knowledge and spread good architectural practice around the team/s they work with. It doesn't mean that the architect doesn't still act as a gate keeper, for example we still have architectural reviews (this for some teams happens at the peer review point as part of their workflow), but by the architects creating the communities of shared knowledge that you mention they are minimising the amount of 'bad' architectural code they encounter in their reviews. I'm all for team PR, leveraging on wiki's, blogs, information radiators, etc.. it is definitely the way forward on advertising your teams hard work. Its certain useful to have a single application where you can view your SC data (commits, commit comments, etc...), team wiki, team blog, etc... but like an all in one hi-fi I have yet to find a tool that can do it all (Jira's integration with Mercurial is pretty cool for example, but it struggles in other areas). I personally don't like architecture by statical code analysis, as SCA can be misleading, but I certainly think it has a place, as long as its metrics are used as a tool which can help the architect zero in on the problem area. As you've mentioned, trust plays a big part in an Agile team, to geniunely empower a team you must trust them. Sadly I have found with many teams I have worked with over the years that this isn't always the case, often trust is 'lip service' from the business. I wrote a post that touches on trust; <a href="http://carlbruiners.com/2012/04/sovereign-teams/" rel="nofollow">Sovereign teams</a> Hi Muse,

Though not inline with the original blog, thanks for sharing this, particularly as you have touched on many issues.

You’ve made some interesting and valid points, you clearly have mastery in the development department, statical code analysis, BDD, etc.. is all very much at more advanced end of development.

My take is that it isn’t only the architect that needs to be empowered, it is important to empower the whole team; BA’s, QA, Developers / engineers, designers, UX, UI, etc…

Architects should be fountains of knowledge and spread good architectural practice around the team/s they work with.
It doesn’t mean that the architect doesn’t still act as a gate keeper, for example we still have architectural reviews (this for some teams happens at the peer review point as part of their workflow), but by the architects creating the communities of shared knowledge that you mention they are minimising the amount of ‘bad’ architectural code they encounter in their reviews.

I’m all for team PR, leveraging on wiki’s, blogs, information radiators, etc.. it is definitely the way forward on advertising your teams hard work.

Its certain useful to have a single application where you can view your SC data (commits, commit comments, etc…), team wiki, team blog, etc… but like an all in one hi-fi I have yet to find a tool that can do it all (Jira’s integration with Mercurial is pretty cool for example, but it struggles in other areas).

I personally don’t like architecture by statical code analysis, as SCA can be misleading, but I certainly think it has a place, as long as its metrics are used as a tool which can help the architect zero in on the problem area.

As you’ve mentioned, trust plays a big part in an Agile team, to geniunely empower a team you must trust them. Sadly I have found with many teams I have worked with over the years that this isn’t always the case, often trust is ‘lip service’ from the business. I wrote a post that touches on trust; Sovereign teams

]]> Comment on SCRUM in name, not in nature by Muse http://carlbruiners.com/2010/10/scrum-in-name-not-in-nature/#comment-353 Muse Wed, 16 May 2012 19:30:08 +0000 http://192.168.0.2/wordpress/?p=122#comment-353 Let's step back and look at the problem(s) aihcrtecture is supposed to solve (I may be completely wrong here, so feel free to correct me) * Reduce waste from rework * Increased changeability of code by avoiding writing frozen codeBoth of these are incredibly important in an enterprise with hundreds of developers working on interoperable systems.Traditional enterprise aihcrtecture tried to accomplish this with architects as gate keepers. They would somehow be responsible for the design of the entire aihcrtecture of an organizations software system, but be so involved in meetings that they wouldn't get much opportunity to see how the code is actually interacting. Decisions which make perfectly rational sense at the architects abstraction layer could cost a lot of money and not provide any additional business value.Agile aihcrtecture requires architects to act as empowerers instead of gatekeepers. Their responsibility isn't to prevent poor design choices, but to use their experience and skills to create communities of shared information.how does this happen?First, they must focus on making important information big and visible. * Code health (however you measure it) * I prefer to measure cyclomatic complexity and unit test coverage, and monitor for improvement over time as opposed to some absolute mandated metric. * Public API Specification * I prefer to use a tool like cucumber to create human readable examples exercising the public API.This is more difficult than it sounds. Making this information big and visible is *TOUGH*. The best way's I've seen have involved using tools like github corporate accounts so that the wiki, build instructions, issue tracker, and source control are all tied into a single streamlined (yet highly adaptable) systemSecond, they must focus on providing the right education * The 4 rules of simple design are pretty crucial * So are code smells and refactorings * What are the common values you share as a dev organization (Small parts loosely joined? Boy Scout?)Flipping architects from gatekeepers to empowerers is by no means an easy task. It requires a hig level of respect and empathy from all involved parties, and a willingness to trust that everyone involved is doing their best to help the organization succeed. Let’s step back and look at the problem(s) aihcrtecture is supposed to solve (I may be completely wrong here, so feel free to correct me) * Reduce waste from rework * Increased changeability of code by avoiding writing frozen codeBoth of these are incredibly important in an enterprise with hundreds of developers working on interoperable systems.Traditional enterprise aihcrtecture tried to accomplish this with architects as gate keepers. They would somehow be responsible for the design of the entire aihcrtecture of an organizations software system, but be so involved in meetings that they wouldn’t get much opportunity to see how the code is actually interacting. Decisions which make perfectly rational sense at the architects abstraction layer could cost a lot of money and not provide any additional business value.Agile aihcrtecture requires architects to act as empowerers instead of gatekeepers. Their responsibility isn’t to prevent poor design choices, but to use their experience and skills to create communities of shared information.how does this happen?First, they must focus on making important information big and visible. * Code health (however you measure it) * I prefer to measure cyclomatic complexity and unit test coverage, and monitor for improvement over time as opposed to some absolute mandated metric. * Public API Specification * I prefer to use a tool like cucumber to create human readable examples exercising the public API.This is more difficult than it sounds. Making this information big and visible is *TOUGH*. The best way’s I’ve seen have involved using tools like github corporate accounts so that the wiki, build instructions, issue tracker, and source control are all tied into a single streamlined (yet highly adaptable) systemSecond, they must focus on providing the right education * The 4 rules of simple design are pretty crucial * So are code smells and refactorings * What are the common values you share as a dev organization (Small parts loosely joined? Boy Scout?)Flipping architects from gatekeepers to empowerers is by no means an easy task. It requires a hig level of respect and empathy from all involved parties, and a willingness to trust that everyone involved is doing their best to help the organization succeed.

]]> Comment on Is limiting what my partner can buy a bad thing? by Heston and Ramsey got it so wrong…. and why Scrum could help in the kitchen « Carl Bruiners http://carlbruiners.com/2012/04/is-limiting-what-my-partner-can-buy-a-bad-thing/#comment-321 Heston and Ramsey got it so wrong…. and why Scrum could help in the kitchen « Carl Bruiners Mon, 16 Apr 2012 17:28:43 +0000 http://carlbruiners.com/?p=595#comment-321 [...] Is limiting what my partner can buy a bad thing? [...] [...] Is limiting what my partner can buy a bad thing? [...]

]]> Comment on The really simple Agile tool – update by A really simple Agile tool – DB structure « Carl Bruiners http://carlbruiners.com/2012/03/the-really-simple-agile-tool-update/#comment-309 A really simple Agile tool – DB structure « Carl Bruiners Wed, 28 Mar 2012 19:47:58 +0000 http://carlbruiners.com/?p=569#comment-309 [...] The really simple Agile tool – update [...] [...] The really simple Agile tool – update [...]

]]> Comment on Introducing the really simple Agile tool by The really simple Agile tool – update « Carl Bruiners http://carlbruiners.com/2012/03/introducing-the-really-simple-agile-tool/#comment-307 The really simple Agile tool – update « Carl Bruiners Mon, 19 Mar 2012 08:29:45 +0000 http://carlbruiners.com/?p=556#comment-307 [...] Introducing the really simple Agile tool [...] [...] Introducing the really simple Agile tool [...]

]]> Comment on Introducing the really simple Agile tool by Clarke Ching http://carlbruiners.com/2012/03/introducing-the-really-simple-agile-tool/#comment-305 Clarke Ching Sun, 04 Mar 2012 12:45:19 +0000 http://carlbruiners.com/?p=556#comment-305 How cool is that! How cool is that!

]]> Comment on Agile Edge presentation by carl9167 http://carlbruiners.com/2012/02/agile-edge-presentation/#comment-302 carl9167 Thu, 23 Feb 2012 07:21:03 +0000 http://carlbruiners.com/?p=534#comment-302 Its read-only, if anyone would like the PPT unlocked, please email me and I'll send over a copy :-) Its read-only, if anyone would like the PPT unlocked, please email me and I’ll send over a copy :-)

]]> Comment on Agile Edge presentation by Aussie Matty http://carlbruiners.com/2012/02/agile-edge-presentation/#comment-301 Aussie Matty Thu, 23 Feb 2012 04:03:17 +0000 http://carlbruiners.com/?p=534#comment-301 Password protected PPT file ... Password protected PPT file …

]]> Comment on Testing Curve by Agile test curve « Carl Bruiners http://carlbruiners.com/2010/11/testing-curve/#comment-299 Agile test curve « Carl Bruiners Sun, 05 Feb 2012 20:32:56 +0000 http://192.168.0.2/wordpress/?p=90#comment-299 [...] test curve This post is an update to my original post Testing Curve. I've had a few emails asking for a more detailed graphic and some advise on avoiding the unheathly [...] [...] test curve This post is an update to my original post Testing Curve. I've had a few emails asking for a more detailed graphic and some advise on avoiding the unheathly [...]

]]>