In the absence of K2

In the absence of K2 being an available choice (consider expenses, resources, environment, support and maintenance that goes with selecting technologies and frameworks), Windows Workflow Foundation (WF) is becoming a viable option.

Not for everyone, but for those that understand Workflow, C# and need to interact with SharePoint in some way or another, it can be a nice option to have available.

Things to take in to consideration with WF is: what can I use for a User Interface if there is any Human to System interaction; how much do I need to know about the plumbing; how much do I need to know about SharePoint (if this is part of the solution)...

SharePoint 2010, InfoPath 2010 & WF seem to make a nice combination in the latest edition of the Microsoft tool sets. WF hasn't made in major leaps and bounds. People used to Visual Studio add-on WspBuilder and the like, will be happy to hear that this type of project set up is now out of the box.

A lot of the plumbing that was once a tedious affair in Feature.xml file, is now handled for you for the most part... not quite completely but with little effort, it all sings and dances together quite nicely.

Debugging through Visual Studio 2010 has also been taken in to account such that all one needs to do is hit F5 and the solution is deployed and awaiting an event to be triggered. For those that worked on previous incarnations of WF, this is quite amazing stuff. No more attaching the debugger manually after a painful deploy, or having to write batch files to automate the process.

InfoPath 2010 integration is a little painful still as the solution doesn't understand the .xsn extension still. But this can be manually associated with a little massaging.

Key to this is getting the Elements.xml (or workflow.xml depending on your preference for naming the elements manifest) to point to the right file path. In the new project structure, everything appears in a folder, which means you need to ensure that the .xsn files are in that folder correctly.

I used to try and avoid solutions that had MOSS 2007, InfoPath 2007 and WF as its technologies of choice like a dog trying to avoid worm tablets! However, these new solutions have had spared some thought for the lowly developer and tried to make our lives a little.

Whilst this still remains a very code dependant technology, and really Microsoft haven't put much effort in upgrading the framework (alot of it still using Framework 3.5), at least the deployment part has been simplified.

Not really fair to make a comparison between whether to use WF or K2, as a developer K2 is hands down the better tool (and is built on top of WF therefore providing you with everything WF would give you), in the absence of a choice, there's no need to be scared of WF.

Reading properties in the workflow of the Metadata columns from a SharePoint List or Library, creating user tasks to approve or reject tasks, notifications, workflow history etc are all things that are, with a little bit of configuration and programming, quite simple to establish. With the simplified way to debug these days, finding and correcting bugs in your code is also less painful than it once was.

I wouldn't say I am looking forward to more WF projects in the future, but I am definitely less apprehensive about it.

My recommendation would be to give it a go, create a simple approval workflow and check it out for yourself. If you have SharePoint 2010 and InfoPath 2010 as well, have a go at all three together and see how the experience compares.

Happy programming.

Agile misconceptions

Agile and Scrum are some really handy buzz words. A buzz word can be defined as a “…term of art or technical jargon that has begun to see use in a wider society outside of its originally narrow technical context by non-specialists who use the term vaguely or imprecisely…” (as stated in Wikipedia).

As a consultant I get the benefit of working in different environments and working with different methodologies across various industries. I've had the benefits of seeing highly skilled and motivated people impress upon me the ideals of a good working methodology to only then butcher the implementation of it in practice.

In almost all of the projects I’ve been involved with that stated they were either Agile or following a Scrum methodology were merely using buzz words to sound impressive. I’m not easily impressed.

Agile is not Scrum. Scrum is Agile. There are many implementations of the Agile methodology, Scrum is just one such implementation. There is Lean, TDD, eXtreme Programming (XP) and the list goes on and on. Agile means an iterative development where requirements and solution evolve through collaboration between self-organising cross functional teams. Essentially that the scope of work is not fixed. It is continuously reviewed and re-prioritised based on collaboration between the Client and the Vendor. You may here terms such as Product Owner and SCRUM Master blah blah blah.

Anymore buzz words? If the terminology has not been clearly defined before you use it, then it is a buzz word and either you don’t understand it, or the person you are stating it to does not understand it. Assume nothing.

More often than not projects fail to factor in how much the client affects the implementation of that methodology. Take for example the Waterfall methodology. Before you stop reading, I'm not about to suggest that this is good practice, there's a point coming. Waterfall is quite simple, it is not confused, misconstrued, misinterpreted... If someone was to say they were implementing a Waterfall project, you know straight away what it entails: heavy initial documentation; development of some type; UAT; and project completion. Simple, might not be that effective, but that’s for someone else’s blog.

If someone was to say they were following an Agile methodology and implementing a Scrum project, we might each of us have a difference of opinion on how this project would be implemented. The client would have a view, the Project Management Office (PMO) would have a view, and the development team would have a view. Those views might well be very different.

This is where I believe the process gets bogged down. People know the buzz word; they don't often know the definition. Very few people will say they don't know Agile, or they don't know Scrum in the city where I'm from. Seems everyone knows it. Great. Define it for me.

Maybe you come across someone that may have read the Agile Manifesto. Well done, but does that mean you understand what makes a successful implementation of it? Maybe, maybe not. The manifesto is a high level set of principles, it is not a definition.

If I am going to implement a methodology in to an organisation successfully, then it needs to be defined accurately. It needs to be defined in a way that the Client understands what it is they will get out of it (ROI) and how the project will be delivered (artefacts). Very few projects I have worked on do this, or do this well. The Client hears the buzz word, they are smart, we are smart, let's move on and we can argue at the end of the project when it is time to pay up!?

Take the time to go over each step of the process, even if it means making them listen to something they already know. What it will do is ensure that you, the Vendor, and they, the Client, are talking the same language. Not in principle, but in practice. We will do X, followed by Y, followed by Z in a continuous pattern and deliver you BLAH. If they have any questions, queries, concerns, it gets ironed out straight away, rather than when it is time to pay.

Agile does not mean: no documentation. It does not forsake planning and envisioning. These are still key and critical parts of the process. They ensure that there is a plan, a vision and later determine the Product Backlog. The Product Backlog is the high level plan of what is being delivered at a point in time. This should be continuously revised.

Back to documentation. How much is enough? How much is too much? Where do you draw the line with documentation? I was at a recent presentation from Dave Thomas and I asked the question of where this line is. His answer was simple, between 10-15% of the overall project length. He also phrased it in his slides as: “… to understand enough of the vision of ‘tomorrow’…”

So how do we get this vision of tomorrow? In Agile speak it comes down to:
• Define the Problem;
• Define the person affected by the problem (Persona);
• Describe the problem succinctly (Stories);
• Define the criteria of User Acceptance (Acceptance Criteria).

Defining the problem should include evidence that the problem exists. This will also assist later when we attempt to define the criteria for acceptance.
Each Persona described should have a definition of that Persona (description of their role and background information such as education) so that everyone is aware of the type of person the solution is to be aimed at.

Documentation shouldn’t just stop at “Envisioning” as Dave Thomas so eloquently called this process, he went on to suggest that this stage include common tasks such as: GUI Architecture and Design concepts (layouts; navigation etc); GUI Prototyping; Software Architecture (structure of new, changes to existing); Buy vs Build Evaluation; Product vision roadmap; Paper prototypes describing the final output; Wireframes and interface concepts; System architecture diagrams and models; Proof of Concept software; Return on Investment strategy…

I’m not going to plagiarise everything he went on to say, but as you can see, there’s a lot of documentation that he sees as essential to a successful implementation of an Agile project. It’s not just roll the sleeves up and start coding or delivering output.

Agile works. It works well. But like anything, it only works when all the parties involved have the same understanding. You, the Vendor, understand what the Client wants, and they, the Client, understand how they are going to get what they want.

The agreement between what the Client wanted, and what you delivered is in the Acceptance Criteria. Quite often you get to the finish line and go live, and the end users see the deliverable for the first time and what they expected wasn’t what you delivered. They expected an iPod, but we delivered a radio! They expected a laptop, but we delivered a desktop!
Even in Agile projects, especially in poorly implemented projects, this is a common occurrence. This is not just something that happens in Waterfall projects. In the typical projects that I seem to be involved with it is either: poor or lack of planning at the start (Scrum implementation); or too much planning at the start and the scope should have changed but remained static (Waterfall implementation).

Take the time to develop a clear vision of what the Client wants. Measure that in terms of how it will be accepted. Revisit the Vision and the Acceptance Criteria after each iteration to ensure that the vision is still accurate. Everything that is going to be delivered should have an accompanying Acceptance Criteria. Nothing should be considered completed until the Client accepts that the criteria have been met. The Acceptance Criteria should be a collaboration between the Client and the Vendor so that both sides understand the meaning of completed.

There are a lot of opinions on which implementation of Agile is a good one, or whether Agile is a good methodology to follow. What I think makes sense, is that whichever methodology you choose to follow, that you, the Vendor, and they, the Client, are on the same page. That you both understand fully the process of how the project is going to be delivered, and most importantly, there is an understanding of how the project will be measured as completed.