Building Correctly vs Building the Correct Thing

Building something correctly vs building the correct thing. Agile Mindset implemented correctly delivers to both sides.

Product Owners defines what needs to be delivered, Architecture determines the feasibility and how the products will be delivered and finally the Development team will do the actual delivering.

Things can go awry if all three key parties are not communicating, empowering and trusting each other. Architects, in particular, can have a huge impact in defining what enablers need to be in place for the Development Team to work against. However, they should take into account expert feedback from the team in terms of tools and techniques (and not consider themselves as the only experts in the team) otherwise, there is a huge risk of over-complicating the solution for the sake of using bleeding-edge technology.

Additionally, getting your products in front of customers is so darn important to ensure that you are delivering to their expectations AND can adapt accordingly to any gaps. The whole premise behind a great Agile mindset is soliciting for and accepting early feedback from the customers. Immature product owners will frequently see the release of minimal features to have a negative impact on the customers, but provided that expectations are properly set, customers are the single most important source of feedback that the Development team can use to deliver something the customer expects and needs.

The Product Owner while being the business and market expert is still not the customer.

And in saying all that, strive to deliver in as cool a way as possible 🙂 After all, the journey matters too! 🙂

Documentation in Agile

Increasing the Agile mindset and creating higher performing teams can pose quite a bit of a challenge even to the most experienced of agile coaches.

Will endeavor to set up a weekly post with a small collection of hints and tips and gotcha’s to avoid 🙂

“Just Good Enough”…

Being Agile doesn’t translate to no documentation. Instead, in Agile Scrum, documentation should be “Just Good Enough“. Traditionally, entire cottage industries are created through the need to document and audit everything. This is not necessarily so true in Agile. Stories and Tasks are documented just enough to cover the delivery of the feature. Once the feature is delivered, it is very rare for anyone to refer back to old stories and tasks.

Having too much documentation will run the risk of becoming mini-waterfall within your sprints.

Epics and Feature Briefs

Epic and Feature briefs are small one-pagers that describe at a high level the epic or feature being developed and has sufficient information to allow for meaningful conversations to take place. If you are seeing mini-project initiation type of documents detailing each epic or feature, you are running the risk of over-documentation.

Avoid distributing risks and assumptions across these briefs. Instead have a central risk and assumptions area in your wiki/team space and link the relevant epic or feature Id there.

Documenting User Stories

Documenting user stories should follow the INVEST rule and focus on having sufficient information to allow a delivery team to have a conversation with the product owners and break the story down into technical tasks as part of their sprint planning.

I will not explain INVEST here – there are many great articles on the web that can do that significantly better than I can 🙂 The main purpose here is to ensure that there is enough for that conversation to take place.

Maintaining Traceability

Gotcha #1: Technical teams may start breaking down their tasks as per the screen wireframes (instead of taking each story). This will result in a disconnect between the stories and the tasks. A screen wireframe may have multiple stories within it, but the team may have difficulty in assigning the right tasks to the right story.

The result will be a single story that will suddenly have a lot of tasks in it and other stories with zero tasks. If you see this, stop immediately, and re-focus the delivery team to work off the stories themselves and not the wireframes in isolation.

It is also useful for the team to have a holistic view of the wireframe screen they are delivering, and possibly superimpose the story cards over the screen. This gives them the overall view of the screen and expected behavior and still allow them to go into detail as required.

It is key to review the stories and tasks and ensure traceability between the “what/why” and the “how”.

New Agile Items added

Been collecting a lot of visual resources over my time as an Agile consultant. Just thought to add these to the site portfolios 🙂

If you need anything similar created for your own organization, please feel free to contact me and we can work out how to get some of these across for you 🙂

Dee!

ASP.NET – How to set culture in web.config to change regional settings

In ASP.NET, if you get messages similar to the following:

* String was not recognized as a valid DateTime
* The conversion of a varchar data type to a datetime data type resulted in an out-of-range value.

It is feasible that the webserver and/or Db is running on different regional culture sets.

To fix this,add a globalization section to the Web.config file, and then set the uiculture and culture attributes, as shown in the following example:

 <globalization uiCulture="en" culture="en-NZ" />

The full list of cultures can be found here:
https://msdn.microsoft.com/en-us/library/system.globalization.cultureinfo(v=vs.110).aspx

MVC error: “System.Web.WebPages. Razor.Configuration. HostSection cannot be cast…”

Got this error when doing a partial deployment to an MVC ASP.Net website. This one took me a while to figure out as the some of the changes in the code was done by someone working with an earlier version of Visual Studio (while I was working with 2015)..

[A]System.Web.WebPages.Razor.Configuration.HostSection cannot be cast to [B]System.Web.WebPages.Razor.Configuration.HostSection. Type A originates from ‘System.Web.WebPages.Razor, Version=2.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’ in the context ‘Default’ at location ‘C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Web.WebPages.Razor\v4.0_2.0.0.0__31bf3856ad364e35\System.Web.WebPages.Razor.dll’.

Took a while to find out the root cause. Apparently this is due to incorrect versions specified in the web.config in the VIEWS folder (not just the root folder).

Simply replace the configsection in there to reflect the new version:

 <configSections>
 <sectionGroup name="system.web.webPages.razor" type="System.Web.WebPages.Razor.Configuration.RazorWebSectionGroup, System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
 <section name="host" type="System.Web.WebPages.Razor.Configuration.HostSection, System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
 <section name="pages" type="System.Web.WebPages.Razor.Configuration.RazorPagesSection, System.Web.WebPages.Razor, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35" requirePermission="false" />
 </sectionGroup>
 </configSections>

Hope that helps!

ASP.Net Tip – Open a PDF File in a new window

To Open a PDF file in a new window in ASP.Net:

Html:

 <asp:LinkButton ID="lnkView" runat="server" Text="View File" OnClick="View" CommandArgument="MyFileName"></asp:LinkButton>

(The CommandArgument holds the name of the file – easier ways to pass a filename across, but this is just one of them..)

On the page where the above button is:

 protected void View(object sender, EventArgs e)
        {
            string url = string.Format("ViewPDF.aspx?fileName={0}.pdf", (sender as LinkButton).CommandArgument);  //change name of aspx as required.
            string script = "<script type='text/javascript'>window.open('" + url + "')</script>";
            this.ClientScript.RegisterStartupScript(this.GetType(), "script", script);
        }

Set up a blank aspx page (in the example above, I called it ViewPDF.aspx) and in the page_load:

protected void Page_Load(object sender, EventArgs e)
        {
            if (!this.IsPostBack)
            {
                string filePath = Server.MapPath("~/Reports/") + Request.QueryString["fileName"];  //change path as required
                this.Response.ContentType = "application/pdf";
                this.Response.AppendHeader("Content-Disposition;", "attachment;filename=" + Request.QueryString["fileName"]);
                this.Response.WriteFile(filePath);
                this.Response.End();
            }
        }

This is just sample that takes a PDF filename via querystring and writes the file to display. You can play with the client script to change window properties as required.

Return from Fiji Trip.

Went over to Fiji to visit my friends at Handy Finance Limited. Interesting to see how they are serving quality data and information out to the branches who are not connected directly to the head office. 🙂

Currently they are looking into growing their IT stack to support the ever increasing demand from the business and extending their product range significantly to cater for SME businesses as well. This is an exciting time for them and I wish them all the best in terms of success 🙂

Hello world!

meh.. just started this site.. should have some case studies soon 🙂